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.
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. 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 > > > > > > > > > >
