diatomsRcool
commented
4 years ago - The reason for the voting is so we don't have updates in one place that break a bunch of things elsewhere. It also serves to keep everyone on the same page. Is there another way to ensure this?
- I would suggest a week between PR and merge.
- I would suggest a minimum of 3 +1 votes before PR or committee voting. A 2/3 majority is a quorum on the committees.
From the Standards and Reference Change Management document: "All of the artifacts managed by this process are stored in public Translator GitHub repositories. The master branch of each repository defines the most up-to-date agreed-upon validated version of the standard, code, or document. Direct pushes to master will not be allowed for any of the repositories managed by this process. Instead, amendments to any covered repository must be performed by pushing changes to a branch, and then issuing a Pull Request (PR).
PRs can be commented on by any person, but may only be voted on or merged by: members of the Translator Architecture Committee, for software/documents categorized as “software architecture” members of the Translator Data Modelling Committee, for software/documents/artifacts categorized as “data modelling” members of the Steering Committee, for documents categorized as “governance” See the Roles and Responsibilities document. Discussion and voting will be conducted via comments on the Github pull requests. Votes shall be of the form +1 (“I like it”), -1 (“I dislike it”), or ±0 (“No opinion”). Decisions will be made after resolving any -1 votes. In the unlikely event resolution is not possible, the proposer(s) or dissenter(s) can appeal to the relevant technical committee or the Steering Committee. The voting requirements for merging a pull request depend on the scope of the change as follows:
Minor Documentation changes, such as typo fixes: Requires no -1 votes (lazy consensus). In the event of a -1 vote, a discussion will be conducted around the proposed change, followed by a new vote requiring a simple majority of a committee quorum and at least 3 votes cast.
Code changes and major documentation changes: These changes are primarily for improving or extending the functionality of components, and do not force updates to participating components such as ARAs or KPs. These require at least three +1 votes, no -1 votes (lazy consensus). In the event of a -1 vote, a discussion will be conducted around the proposed change, followed by a new vote requiring a simple majority of a committee quorum and at least 3 votes cast.
Architectural, interface, or contract changes: These are changes that impact multiple Translator teams, often requiring modifications to existing code. These require that the number of +1 votes be at least twice the number of -1 votes (i.e. ⅔ of the votes cast must be in the affirmative), a quorum of the committee has voted, and that at least 3 votes be cast.
Each repository controlled by this process must be associated with a regularly-convened meeting (which can be remote), where reviewing open PRs will be a standing agenda item. Note that more than one repository/artifact may be associated with the same meeting. The SRI team will maintain a master list of controlled repositories / artifacts and associated meetings.
For each domain, proposed changes (GitHub pull requests) will be discussed during regular calls with the appropriate voting committee and other community members. After allowing a reasonable amount of time for stakeholders to comment and/or vote, PRs will be merged or closed, as appropriate, by SRI moderators. Any member of the Translator community is free to propose changes in GitHub and attend the weekly software architecture meetings.
There are concerns that this process is too rigid. Is voting necessary? What happens if there is disagreement? How much time should we allow between PR and merge? How many votes are needed before a PR is merged? What is a quorum?