> 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. 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]> http://db.apache.org/jdo <http://db.apache.org/jdo>
