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

How do we maintain our core documents in the long term? #234

Open
wareid opened this issue Feb 3, 2025 · 3 comments
Open

How do we maintain our core documents in the long term? #234

wareid opened this issue Feb 3, 2025 · 3 comments
Labels
Call for Input Looking for others to weigh in.

Comments

@wareid
Copy link

wareid commented Feb 3, 2025

For clarity, this question is about not only the Vision, but also the Process and the Code of Conduct.

Currently, we maintain our "core" documents separately in either community groups (Process and PWE), or here in an AB taskforce (Vision). This has always been a strange way to do things, as evidenced by issues like this or this. Over the years there has been discussion about moving to IGs for these documents, since IGs give us the structure of a charter, but the openness to ensure broad community engagement on these topics.

The AB recently discussed this at their last face to face, and two possible models for how to do this were discussed:

  1. A single "Governance IG" (name TBD) to oversee and maintain all three documents, working in a task force model for each document to have its own group of maintainers.
  2. One IG for each document, individually chartered with their own timelines and deliverables.

We'd love to get feedback from the community on these ideas, anything we haven't considered, possible issues or opportunities.

@wareid wareid added the Call for Input Looking for others to weigh in. label Feb 3, 2025
@wareid
Copy link
Author

wareid commented Feb 3, 2025

(Personal opinion, though informed by being chair of PWE and the AB).

I'm personally in favour of a single IG model that contains TFs for each document for a few reasons:

  1. Single, consistent work mode and contributing guidelines: while this is possible with multiple IGs, I think establishing a consistent workmode for all three documents is easier in a single IG model where the leads of the documents can work together to establish policies that work for them. We all want community engagement and participation in the development of these documents, but it can be a challenge figuring out "how" to participate when the processes are often different or unclear.
  2. Flexibility for document lifecycles: It is inevitable that there will be periods of high activity and low activity for all of these documents. IGs require charters, which is not a complicated process but a time-consuming one, and having a single charter that accounts for the ebb and flow of the three document lifecycles will be easier to manage than three charters that may need to be spun up at any given time. Having a single IG also means that when a document is in a low activity period, there will always be a group paying attention to see when activity needs to be ramped up.
  3. Low barrier to engagement: Currently, if someone wants to contribute to any of these documents, they need to know which group to speak to and what their processes/policies are. Which repo to report issues in, where to sign up to join, etc. Having a single IG creates a single point of entry, single repository to log issues, etc.

There are definitely potential cons to a single IG model, such as bottlenecking, but I think many of them are manageable with good leadership and awareness. I'd love to get broader input on this though, especially from community members who have either participated in these groups/efforts, or who have wanted to but didn't for any reason.

@mgendler
Copy link

mgendler commented Feb 4, 2025

I'm going to pull in a couple of items from elsewhere to help facilitate the conversation, and then respond myself in a later comment:

From @fantasai regarding Proccess IG:

Since this topic is coming up again, I've drafted a possible charter for a Process Interest Group that attempts to capture the work mode of this CG.

from @plehegar in response (not in full):

I think the draft is a good start for discussions.
Is the AB having an overarching discussion on how it organizes its work items (Vision, Process, Patent Policy, Code of Conduct, etc.) ?

I did a quick comparison with PSIG:
https://www.w3.org/2025/01/psig-charter.html
In my mind, both groups act pretty much the same way:
they propose or suggest changes to the AB for their respective documents (Process, Patent Policy) but don't have a formal role.
they both are empowered to create adjunct documentation to help implement those documents. PSIG produce a FAQ and is responsible for it. Process CG did not produce documentation so far but should feel free to do so (those produced by the AB have been incorporated in the Guidebook overtime, such as [1]).
they both should feel free to review/comment on adjunct documentation/tools produced by the Team to implement those documents (IPR pages/CfE emails/etc, Transition requests/AC email notices/etc).

@cwilso
Copy link
Collaborator

cwilso commented Feb 4, 2025

First, I would like to suggest if there were a single model for all such documents, it should be extended not just to the documents that the AB ostensibly owns, but those of the TAG as well; it doesn't make sense for the Vision/Process/CoC to be owned this way but not the Ethical Web Principles/Design Principles/Privacy Principles.

In order to be transparent about my take: I think it is a bad idea to have a single "governance IG", for multiple reasons. Or more to the point, we already have two, and they're elected: it's the Advisory Board and the TAG, who are capable of (and have!) inviting others more broadly to participate in developing these documents, via other mechanisms (either CGs or open task forces). The AB still have ultimate responsibility to the membership today for the CoC, Process and Vision, as the TAG do for the EWP, DP, PPs.

That's actually desirable, in my perspective, because those groups are elected by the Membership to do those tasks. If you instantiated a Governance IG, the Team would select Chairs, who have a lot of power in controlling how those documents are produced. The point about lifecycles is a valid one, but that's why the AB and TAG are involved; they can put as much or as little priority on revving the documents as is needed, all while being answerable to Membership.

(I will note that the AB has perhaps not taken as direct personal responsibility for the Process and the CoC; I and a few other past AB members participate heavily in those efforts, but many of the AB members do not, and I think they should take more of an interest.)

As for the low barrier to engagement, every one of the documents I've mentioned has links to its Github community and instructions on how to file issues and participate in the evolution; I'd be more concerned about getting more consistent engagement than getting enough.

Finally, I think an open-membership Governance IG becomes a honey pot for distraction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Call for Input Looking for others to weigh in.
Projects
None yet
Development

No branches or pull requests

3 participants