+1. Side note: it is probably better to have a short guide instead of too-wordy How-To-Contribute, that no one actually read :)
вт, 2 апр. 2019 г. в 13:17, Sönke Liebau <[email protected] >: > All, > > as there were no major objections to my summary of the proposed > contribution guidelines I'd like to start a vote on this topic. > > As usual, the vote will stay open for at least 72 hours (probably more, as > I'll be gone for a long weekend starting Thursday). > > > ---- > The proposed principles are: > > Fundamentally we will follow a Review-then-commit workflow with two notable > exceptions: > - Trivial changes (jira issue classified as trivial or bull request marked > by "TRIVIAL:..." ) - these still need to be posted for review but can be > merged after 72 hours by lazy consensus > - To fix a broken build - to be reviewed later, if possible > > Review requirements are separated, for code, tooling, website etc. the > following applies: > If the pull request was opened by a committer, the reviewer can be a > non-committer (chosen by the committer). For pull requests opened by > non-committers the reviewer must be a committer. > > For pull requests that change the content of training material the usual > rules don't apply, as we probably won't have experts for all fields in the > team from the get-go. For this case we will require two reviews, one by a > SME for content, one by a committer for form. If a committer considers him > or herself to be an SME as well one review is sufficient. > > For every commit there has to be either a jira or a pull request (both is > fine too and actually recommended). > ---- > > These are just the guidelines, not the fully worked up contribution guide, > I'll draft that based on these after the vote is finished,but they will not > deviate from what we decide here, just add more detail, so there will be no > additional vote. > > I am +1 > > Best regards, > Sönke >
