[chartering] Using a single repository and notifying the AB

[plehegar]

Talking with the AB yesterday, 2 requests came up:

1. use of a single repository for charters.

Once a charter gets into horizontal review, the draft of the charter must be moved/copied in a single repository, used for all draft charters. Using w3c/charter-drafts is fine.

(This was recommended at the AC meeting in May and clarified yesterday.)

2. create an issue in w3c/AB-memberonly when a charter is ready for horizontal review

(our email notification to the AB don't seem effective enough)

cc @fantasai

[fantasai]

Yes! The goal is to have all the charters in one place so that

• It's easy for charter reviewers (e.g. the AC, HRGs) to find all the in-progress charters and comment on them.
• It's easy to compare charters.
• We can use specially-labeled issues such as these for tracking when "last call" is initiated on a charter, and for tracking the results of horizontal reviews. Filing such an issue can also trigger notifications to the HRGs, AC, AB, TAG, whoever else.
• We can use specially-labeled issues to track the "transition request" for initiating an AC Review, which provides visibility into that process
• CGs and others new to drafting charters can see and learn how it's done, since it's all in one place and all a bit more formalized.

So my suggestions concretely would be:

• Require charters to be checked into the chater-drafts repo for wide review.
• For drafting prior to wide review, groups can use that repo or their own.
• Add a label and a template for filing a "Start Last Call" issue.
• Add a label and a template for filing a "Request AC Review" issue.
• Add a labelling system similar to CSSWG's module tags so that all issues for a particular WG's charter can be easily pulled up.

Some options to consider for storing charters:

• Archive each charter here, grouping "releases" by WG (e.g. csswg/2020.html for the 2020 charter of the CSSWG, etc.).
• Reference archived charters on w3.org, the one here is always "tip of tree". (e.g. csswg.html is the CSSWG's current charter until we start revising it for the next charter, at which point it is the draft of the next charter).

Needs some repo cleanup either way, but this will let people easily compare past/present/future charters (as well as compare charters across groups).

[plehegar]

ok, I'm proposing w3c/guide#179 to help with this issue.

@fantasai , regarding opening issues in w3c/AB-memberonly, I think you're proposing to open separate issues for each stage. While I understand the value for Last Call, I'm not sure I understand the value for "Request AC review". Once the AC review is started, shouldn't we direct folks to w3c/charter-drafts for issues?

[fantasai]

While I understand the value for Last Call, I'm not sure I understand the value for "Request AC review".

“Request AC review” is a request from the charter drafters to the Team to send the charter draft to the AC for formal AC Review. Think of it as a PR transition request for the charter. The Team then decides to send to AC review, or to send back to the charter drafters for further work.

Once the AC review is started, shouldn't we direct folks to w3c/charter-drafts for issues?

During formal AC Review, issues will be filed into WBS, though. Right?

[tidoust]

• Require charters to be checked into the chater-drafts repo for wide review.
• For drafting prior to wide review, groups can use that repo or their own.

I personally like to use dedicated repositories for charters so that I can start from a clean "0 open issue" state when preparing a new version of the charter, so that I can see all issues at once without having to use filters, and so that I can maintain a somewhat readable commit history (see for instance the Media WG charter repository). I would prefer to keep that freedom if possible.

Echoing and surfacing @ianbjacobs' comment against the pull request in w3c/guide#179 (comment), I'm also worried that the requirement to check draft charters that groups may maintain in separate repositories, into the charter-drafts repository, may introduce a source of confusion. And I don't really understand the added value.

I get the need to create one place to track the different charter stages. That's the "Chartering" column in the Strategy funnel. It uses a labeling mechanism to track horizontal reviews. It's a bit hidden because there is no dedicated view of that column.

I would rather propose to extract this chartering column and maintain it in w3c/charter-drafts (or another repository) from now on, without a requirement to also move/copy the draft charter to that repository.

Alternatively, or additionally, we could also use new GitHub project views to create a more directly readable summary dashboard of in-progress charters (the strategy funnel still uses an old "classic" project for now).

Comparison between charters would best be done against approved and published charters. There is a history view for charters per group (e.g. the one for the Audio WG). If that seems needed, we could perhaps create a view for all groups to ease comparison?

[fantasai]

@tidoust The problem I want to solve is:

• The drafts are all in different places.
• The issues are all in different places.
• It's not obvious what all the open issues against a charter draft are.
• It's not easy to figure out where the closed issues against a draft are, in order to review how we got here.
• It's not obvious what the state of the chartering is, or how to get to the next state.

I want to make the process of drafting and approving a charter be straightforward, common, and something people outside the in-crowd can follow. The audience here includes:

• AC/AB/TAG members who want to watch what's going on wrt chartering in general.
• Members of a group that are rechartering.
• A community (such as a CG) that wants to propose a new charter and wants to follow along their own process.
• A community (such as a CG) that wants to propose a new charter and wants to learn from real examples how it's done before they start!
• Horizontal WGs performing review of charters.

Right now, it's a mess. It's hard for people to track what's happening unless they are in the process of drafting that particular charter themselves. And nobody outside the Team seems to really understand what the process is.

Whether the draft itself lives in its own repo or the central repo... I'm not super particular about that. But having them in a central repo means its easier to compare what goes on in different groups, and learn how charter drafting plays out from others. There's pros and cons to sharing a repo, and there are some benefits to it as well. :)

Wrt maintaining an issue count... I think it's important for this repo to have a rigorous and consistent labeling system. Whether we do that with GH labels or [tags] in the subject, we need to do it (CSSWG does both fwiw). I agree we don't want complex filters, but one keyword is not hard.

For the history, if we keep the drafts in a central repo, it's easy to retrieve history off a folder or a file. (Example). (If you're concerned about branches and merges, we can require rebasing for commits.) Whether we require it or not, though, I think we want to allow it.

[jyasskin]

+1 to @tidoust that it's nice to have charters in separate repos, and of course also to @fantasai that it's good to have them all in one place.

Both could be satisfied by either

1. creating a w3c-charters github org, with each charter in its own repo within that org or
2. a naming pattern like we see with https://github.com/w3c?q=webappsec.

I'd lean toward a separate org.

[wareid]

There might be another solution to this problem with GitHub. We could use a projects board, which would allow each charter to continue having it's own repo, but the Strategy team could track each one through the board, there could be a view for the AB of all of the "current" charters (or whatever other filters we'd like to have), and we could likely set up automation that would log an issue to ab-memberonly when a new charter is added to the list. The Strategy team would also then have a single location to track things across multiple repos.

[nigelmegitt]

-1 to a separate org
+1 to separate repos
+1 to a projects board

[csarven]

Separate repos forking the template repo may be key as that would allow different communities to do their own thing / process while staying up to date with the common developments. A single/central repo for all charters may be too noisy irrespective to how the information is organised and processed.

Pardon me if this was already mentioned but the other concern is continuity in the charter development, where once it lands on horizontal review, W3C team review, and member review, they're all reviewing with a particular snapshot of the charter.

Moreover, it needs to be absolutely clear as to who is making the changes to the charter, e.g., while a community may propose a charter, there are Team decisions that follow the proposal, such as team contact, chairs, workspace, and so forth, where the community does not have the authority to update afterwards. Similarly, AC may request changes and Team or the community may update later on. This type of information and how that's managed and communicated should be taken into account.

[nigelmegitt]

Separate repos forking the template repo

GitHub does not allow an organisation to fork its own repo: you'd have to create a new repo based on a template, but it would not be connected to it in any automated or mechanistic way without some bespoke scripting.

[plehegar]

We have a project board, which is purely a filter over the issues.