Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial ActivityPub Maint WG charter template. #2

Merged
merged 2 commits into from
Oct 18, 2024

Conversation

dmitrizagidulin
Copy link
Member

This is a sample (to be discussed with the CG) charter template for the continuing discussion of a potential Working Group, based on a minimal stock W3C template.

Notes:

  • Narrowly scoped as an ActivityPub (and ActivityStreams and ActivityVocabulary on which it depends) Maintenance group.

@bumblefudge
Copy link
Contributor

bumblefudge commented Sep 27, 2024

Would it make sense to have "one WG per protocol/family" and have a separate [maintenance?] WG proposal for the micropub/microformats deliverables?

As mentioned in the other thread, the LinkedData Notifications work kind of straddles the line between AP and another protocol family (Solid), and if that kind of interface were in scope for an active WG, it might be more at home there than here (in this particular case, there is no Solid WG, and the WG that does work on Solid interfaces isn't working on that layer). There is a more timely and urgent work item i'm interested in, though: IndieAuth and how it relates to ongoing FedCM work in FedID. In the case of this BYOIDP prototyping effort in that CG+WG, I would almost rather that work move into the FedID working group (or at least cooperate closely with them) to make sure they can quickly iterate (and even break indieauth if needed) to be absolutely sure they end up with a version of IndieAuth that works hand-in-glove to post-cookie OIDC tooling and up-to-date OAuth ergonomics, particularly if the alternative is a long and drawn-out search for the right (new, needing to be chartered still) WG on our side of the fence.

I personally believe the AP work items are best served by a strictly Maintenance-mode (and strictly focused) WG but it sounds like maybe some non-AP work items are better served by a separate WG in a different mode with different timelines and work modes.

P.S. For those just finding out about this charter "design space", there was a pretty detailed thread on the subject last October, all branches of which are probably worth [re]reading for context.

@bumblefudge
Copy link
Contributor

bumblefudge commented Sep 27, 2024

oh, another example just occurred to me: if the candidate analysis from the e2ee CG work item lands on profiling an IETF protocol, wouldn't that protocol's standing WG (at IETF) be the one to continue work on after CG report? the best WG to do further work at might not always be at w3c!

Co-authored-by: Sarven Capadisli <info@csarven.ca>
@dmitrizagidulin
Copy link
Member Author

Multiple weeks review period passed; discussed it during WG call, also sent out notifications on mailing list, forum and fediverse. No objections from the community.
Since this is just an initial draft proposal, merging (to continue the conversation).

@dmitrizagidulin dmitrizagidulin merged commit 7077c51 into main Oct 18, 2024
@dmitrizagidulin dmitrizagidulin deleted the wg-charter-ap branch October 18, 2024 00:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants