Hi, will this be a "sorta kinda C4" then or do we want to implement the whole thing as described in https://rfc.zeromq.org/spec:42/C4/ ?
I ask because what you describe Floris is an interesting idea but I do not see the parallel to C4 as that process clearly has maintainers who merge PRs of others, which I think of as a Good Thing. I mean this part of the protocol: - A "Contributor" is a person who wishes to provide a patch, being a set of commits that solve some clearly identified problem. - A "Maintainer" is a person who merges patches to the project. Maintainers are not developers; their job is to enforce process. - Contributors SHALL NOT have commit access to the repository unless they are also Maintainers. - Maintainers SHALL have commit access to the repository. I also like the whole Problem -> Solution idea as basis for development of the project (section 2.3). Giving everybody commit rights who successfully merged a PR is a different idea that could be experimented with, but I would not call it C4. Cheers Oliver On Tue, 15 Nov 2016 at 21:18 Floris Bruynooghe <[email protected]> wrote: > Cool, I'll create a PR against CONTRIBUTING.txt, but I'll re-read C4.1 > again first to incorporate Ronny's comments better. > > Floris > > On 14 November 2016 at 14:59, Bruno Oliveira <[email protected]> wrote: > > Hi everyone, > > > > I like the idea as well. As Floris mentioned, giving people commit > access is > > certainly a good way of motivating new contributors. > > > > Anyone up for writing up those guidelines so we can review them and > decide > > if we want to move in that direction or not? > > > > Cheers > > > > On Mon, Nov 14, 2016 at 5:42 AM Ronny Pfannschmidt > > <[email protected]> wrote: > >> > >> Hi All, > >> > >> i believe that when we do something like this, we should lean in the > >> direction of C 4.1 > >> and focus on enabling more people to merge good pull requests of others > >> (we already started to follow a informal process where we no longer > >> self-merge until approval) > >> > >> With the review Approval system that came to github i feel that c4.1 it > >> not up to date for gh > >> (i.e. self merge after approval looks like a valid move now) > >> > >> I like the idea of slowly iterating towards a more open and inclusive > >> process. > >> Readily offering commit bits to people that Demonstrate > >> they can honor the Contribution Process is a beautiful first step. > >> > >> -- Ronny > >> > >> Am 14.11.2016 um 03:52 schrieb Floris Bruynooghe: > >> > Hi all, > >> > > >> > A while ago Ronny proposed to adopt the ZeroMQ C4.1 process. While > >> > the discussion there never got very far (and I forgot to pick it up at > >> > the sprint) I'd like to propose a rather less radical workflow while > >> > attempting to make it easier for people to get on board. > >> > > >> > Basically I'd propose to give commit access to anyone who created a PR > >> > and followed it through to it being successfully merged (with > >> > changelog etc etc all done by the new contributor). > >> > > >> > The main reason to propose this is because right now we don't really > >> > have a clear policy on when someone joins the committers. And it is > >> > much more inclusive to write down clear rules for this. Gaining > >> > commit access is generally empowering and motivating and a good way to > >> > include new members in the development. > >> > > >> > What do other people think? > >> > > >> > Floris > >> > _______________________________________________ > >> > pytest-dev mailing list > >> > [email protected] > >> > https://mail.python.org/mailman/listinfo/pytest-dev > >> > >> _______________________________________________ > >> pytest-dev mailing list > >> [email protected] > >> https://mail.python.org/mailman/listinfo/pytest-dev > _______________________________________________ > pytest-dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/pytest-dev >
_______________________________________________ pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
