Governance document: questions and clarifications

[dgar...@gmail.com]

Dear PMC team,

I have been reading the Codementa PMC, and I think you have done a great job.

I have some small questions that would be great to clarify. Please find them below:

• "The CodeMeta Project entails the development and maintenance of the CodeMeta vocabulary, crosswalk table, website, software and other related content". Shouldn't we say something about potential extensions by the community?
• I am a little confused about committers. One paragraph states that there are no requirements to be a committer "Anyone can become a committer; there are no special requirements, other than to have shown a willingness and ability to participate in the project as a team player". But the next paragraph states that a new committer has to be accepted by a vote of the PMC: "Once they have been nominated, there will be a vote by the project management committee (PMC; see below)".
  • "Anyone can become a committer" -> shall we clarify with "Anyone can become a committer candidate" ?
  • New committers "can" be nominated, or "must" be nominated? I.e., are there any other ways of becoming a committer apart from nomination? Can you volunteer to be a committer?
• How can consensus be reached in case a proposal has multiple supporters in favor and against?
• Is there a minimum support needed for lazy consensus? I feel like if someone starts issuing too many proposals, maybe not everyone will be able to catch up and some decisions may be accepted without further review.
• Can accepted proposals be reviewed? What if we realize some change needs to be undone?

Thanks in advance,

Daniel

[Matt Jones]

These are great points.

I agree with your `candidate` phrasing. I think a PR-based contribution model with review is better than enabling really broad commit access.

For consensus and contributing guidelines, I'd like to propose that the process we used in Science on Schema,org worked quite well, enabling both broad contributions and development consensus on approaches and changes. We used "Architectural Decision Records" which is a simple markdown document explaining the decision point and pros/cons. For bigger issues, we developed an ADR that allowed us to articulate a proposal, and then we would discuss that at our monthly meetings.  Sometimes we had to iterate on those over several months to work out the issues. It was important to have the time to discuss the issues "live" over zoom because that was the time people really brought a laser focus to the issue at hand. Some links:

• ADRs: https://github.com/ESIPFed/science-on-schema.org/blob/master/decisions/README.md
  
• Contributing document: https://github.com/ESIPFed/science-on-schema.org/blob/master/CONTRIBUTING.md

Matt

Matthew B. Jones

ORCID: 0000-0003-0077-4738

Director of Informatics R&D, National Center for Ecological Analysis and Synthesis

PI, NSF Arctic Data Center

Director, DataONE program

University of California Santa Barbara

--
You received this message because you are subscribed to the Google Groups "codemeta-pmc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codemeta-pmc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codemeta-pmc/2d4a4d43-4783-4c41-8dc7-c32dd6336ecan%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Carl Boettiger]

Really appreciate the work of everyone here, great community effort.

Just wanted to chime in with my support for the contribution model Matt describes in science-on-schema, as an outside observer there I also think that has worked really well and provides a very instructive example in a project with very similar needs and objectives.

- Carl

---
http://carlboettiger.info

To view this discussion on the web visit https://groups.google.com/d/msgid/codemeta-pmc/CAFSW8xkX9JGT1iwrgSRpzPQE2Rj9GRawn%2BJmY6LDvzXc_jc1pw%40mail.gmail.com.

[dgar...@gmail.com]

Thank you Matt, Carl,

I think the proposed approach works for me too.

So then a committer (i.e., the person implementing the changes accepted in the proposals) would  have to be a member of the PMC, or an accepted committer as per the guidelines above, right?

I still don't know how would this fit with lazy consensus, minimum support and how the community is supposed to express their opinion (beside voting +1 on the template proposal). Can we clarify this in the governance document?

Best,

Daniel

[Morane Gruenpeter]

Dear Daniel and all,

In my interpretation, the committer group is a group of individuals that have the technical right to commit but are not necessarily part of the PMC, also PMC members are not necessarily committers.

The idea is to have the community vote with +1

Then the PMC validates the lazy consensus if there are no issues.

Finally the committer group integrates the PRs that are accepted by community and validated by PMC.

Here is the doc link again: https://hedgedoc.softwareheritage.org/codemeta-governance?both

I've changed the timeline, since we are a bit behind.

Best regards,

Morane