Hi Lars, I think we might codify this as RTC with an exception that if someone wants to commit a trivial or non-controversial patch, they still need to post the patch for review and specifically request lazy consensus after 72 hours or some other time we deem relevant to this project.
Craig > On Mar 13, 2019, at 2:21 AM, Lars Francke <[email protected]> wrote: > > On Mon, Mar 11, 2019 at 4:34 PM Craig Russell <[email protected] > <mailto:[email protected]>> wrote: > >> >> >>> On Mar 11, 2019, at 6:35 AM, Lars Francke <[email protected]> >> wrote: >>> >>> Okay, any other opinions? >>> >>> I don't necessarily need "Bylaws" but a good "Contributors Guide" is one >> of >>> my pet peeves. So as soon as we have the website up and running I'd like >> to >>> get some content up there. >> >> Yes, a contributors' guide is a great thing to add to the user-facing site. >>> >>> I'm usually in favor of review-then-commit but in our case I'm not sure >> if >>> that's always going to work. >>> Ideally we'd have people contribute stuff that neither of us is - >>> technically I mean - able to review as we won't have experts for every >>> single field in the committership initially. >>> But we can of course review for form and style etc. >>> >>> Other than that I'm in favor of requiring a +1 from another committer to >>> commit anything but this can be painful for small things (e.g. a single >>> typo). For Hive we established a rule that for small changes (at >>> contributors discretion) after a delay/request for reviews of 72h or so >> it >>> can be committed without feedback. >> >> This sounds reasonable. It's a combination of RTC and CTR with lazy >> consensus. Formally, I think it would be described as CTR with discretion >> to wait until another committer has reviewed a "large" change. >> > > I understand what you mean but I (others might disagree) would like to see > it codified as RTC and have the commit without a review as the exception > not the other way around. This has been a major pain for me as a "lone" > non-big-corporate contributor to various projects. You see things happening > without discussion on any public mailing list/Jira. > > > >> Regards, >> >> Craig >>> >>> Cheers, >>> Lars >>> >>> On Tue, Feb 26, 2019 at 10:11 PM Sharan Foga <[email protected]> wrote: >>> >>>> Hi >>>> >>>> I'd be happy with having both models of Jira and Github in place too. >>>> >>>> Thanks >>>> Sharan >>>> >>>> On 2019/02/25 19:06:28, Lars Francke <[email protected]> wrote: >>>>> On Mon, Feb 25, 2019 at 5:37 AM Kenneth Knowles <[email protected]> >> wrote: >>>>> >>>>>> On Fri, Feb 22, 2019 at 2:31 PM Lars Francke <[email protected]> >>>>>> wrote: >>>>>> >>>>>>>> >>>>>>>> Bylaws have gone out of fashion and it’s generally recommend that >>>>>>> podlings >>>>>>>> (and TLP) don’t have them and use the “default”. >>>>>>>> >>>>>>> >>>>>>> Really? I didn't notice. >>>>>>> >>>>>>> >>>>>>>> As the default is often unclear I've created a default simple set >>>> that >>>>>>>> graduating projects can use, [1] Legal and board have reviewed >>>> this. >>>>>>>> >>>>>>> >>>>>>> That's a good starting point. What I struggle with is that every >>>> project >>>>>>> works slightly different in things like: Commit-then-review or >>>>>>> review-then-commit or whether ReviewBoard needs to be used or patches >>>>>> need >>>>>>> to be attached to Jira etc. >>>>>>> These rules are often not written down which makes it hard to >>>> contribute. >>>>>>> This might be a particular pet-peeve of mine because I do - nature >>>> of the >>>>>>> job - lots of "drive by" contributions but I'd still love a clearly >>>>>> defined >>>>>>> set of rules on how we want to operate. >>>>>>> >>>>>>> This includes - and I don't actually know what works there these >>>> days and >>>>>>> what doesn't - the Github use. >>>>>>> If anyone knows what's allowed and possible it'd be great if you >>>> could >>>>>>> share. >>>>>>> >>>>>> >>>>>> At this point, the GitHub pull request model is a de facto standard in >>>> my >>>>>> mind. It works great with ASF infra. >>>>>> >>>>>> The most important thing being that you don't have to read a project's >>>>>> contribution guide to know how to *request* that they *pull* from your >>>> fork >>>>>> of their code. Great for drive-by contributions. If a project doesn't >>>>>> basically follow this model, I don't trust them to accept outside >>>> input. We >>>>>> should definitely use it. I would guess users will be much more likely >>>> to >>>>>> also want to casually contribute bits here and there, compared to >> other >>>>>> projects. Let's make it easy and fun for them (and bring them on board >>>> :-). >>>>>> >>>>> >>>>> I agree that lots of projects use it but most projects I work with work >>>>> differently (e.g. Hadoop, Kafka, HBase etc.). Some do have a model >> where >>>>> both ways are accepted (Jira & Github). I myself am not the biggest fan >>>> of >>>>> Pull requests. I'm against using it as the only option. I like the >>>>> "old-fashioned" way of attaching patches to Jira. It doesn't lock me >>>> into a >>>>> workflow provided by a 3rd party. I can download everything offline and >>>>> prepare a review offline as well. That's not possible with Github (I >> can >>>>> download the code but I can't prepare a review for the website >> offline). >>>>> >>>>> But as I said: I definitely agree that it makes "drive-by" >> contributions >>>>> easier so I'm in favor of having both models. >>>>> >>>>> Lars >>>>> >>>>> >>>>>> >>>>>> Kenn >>>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> Justin >>>>>>>> >>>>>>>> 1. https://wiki.apache.org/incubator/DefaultProjectGuidelines >>>>>>> >>>>>> >>>>> >>>> >> >> Craig L Russell >> Secretary, Apache Software Foundation >> [email protected] <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>> http://db.apache.org/jdo >> <http://db.apache.org/jdo> < >> http://db.apache.org/jdo <http://db.apache.org/jdo>> Craig L Russell Secretary, Apache Software Foundation [email protected] <mailto:[email protected]> http://db.apache.org/jdo <http://db.apache.org/jdo>
