Improving Transparency: Advisory Committee's Role and Community Involvement

[Martin]

During this week Advisory Committee member we did a review of the document and provided the following changes

• clarified the terminology around contributor and project member (see my answer to Tom below)
• more details regarding restricted fund, including
  • a vote from the Advisory Committee before any application. With an expanded Advisory Committee, we should have a better representation of what the community wants to invest in. This process should help get a consensus on the scope before the work gets started.
  • Staff paid from a restricted grant must work first on the scope of that grant.
• grammatical edit

Tom, thanks for the review.

@tfmorris

• committer vs contributor has a very specific definition on Github. Committers have the ability to approve and merge pull requests. Contributors can do a wide variety of tasks including opening pull requests (code or documentation), translation, peer support, issue triage, marketing, etc
• the draft seems to conflate recognition of contributors (which is a nice thing) with granting privileges to them (which is a necessary thing)

The Advisory Committee provided similar feedback, and suggested the following changes which have been integrated in the document:

• Contributor are anyone contributing to the project (what was called contributor-at-large and contributor in the initial document).
• Project Members or Members are anyone who can vote a form working group (previously named contributor)

I suggest renaming the Core Developer group to Committer to stick with the @tfmorris definition above.

@tfmorris

• voting should be amongst the members of the group being joined, so no techies voting on membership in the marketing committee or vice versa.
• two merged PRs is too low a bar for being granted commit privileges. The committers should decide what the bar is, but I think it'll be more like "demonstrated technical ability and willingness to follow team guidelines." Some developers might meet this bar immediately, while others might take some time to be ready.

I agree. The "two PR merged" comes from this initial post and is up for discussion. In the proposed governance, it will be up to each working group to decide how to select its members and document it in their project charter.

@tfmorris

• the concept of "working group" seems fuzzy to me. Some of the things listed seem like individual roles (e.g. release manager) rather than groups and others should be open to anyone who wants to pitch in without any barriers to entry (e.g. peer support)
• issue triage doesn't need to be done by developers. It would be a great way for someone who's familiar with the product, but not necessarily technical, to contribute. It would be nice to have enough help here that we could set a goal like "all issues will be acknowledged/triaged within N days" where N is TBD.
• requiring forum moderators to transfer issues to Github introduces a bottleneck and doesn't scale. The users should do this themselves and we should have the necessary supporting documentation in place to make it straightforward for them to do this.
• I think we currently accept translations from anyone. We could make this more restrictive, but I don't think we've had any issues so far.

I'm sorry if the document was unclear. I agree that anyone is welcome to contribute the way they want without being a project member or part of a working group. Working groups are a way for individuals doing a specific type of contribution to self-organize and take ownership of a part of the project. Creating a working group helps to (1) recognize regular contributors, (2) better structure the process around specific tasks, and (3) request funding.