Agree on the contributors guide, that should be a high priority for us. I imagine (probably more hope) that we have a higher than usual drive-by commit rate and probably overall contributor count due to the highly "fragmented" (in a positive way) nature of our content. We discussed this in another thread [1] as well and I looked up some examples around this.
Copy and pasting them here for reference: A few examples of how other projects have handled this are: Hadoop: https://cwiki.apache.org/confluence/display/HADOOP/How+To+Contribute Hive: https://cwiki.apache.org/confluence/display/Hive/HowToContribute HBase: http://hbase.apache.org/book.html#developer Spark: https://spark.apache.org/contributing.html Kafka: https://kafka.apache.org/contributing Personally I think that Spark has done the best job of structuring the page and assisting new people in finding ways to get involved. Maybe we can refer to that when it comes time to create our "contributing" page. Also agree on the +1 rule with "Minor" changes being exempt. We should probably come up with a few examples of what "minor" means and have a clear requirement of how these are to be tagged/marked, so that one can filter for them. Best, Sönke [1] https://lists.apache.org/thread.html/850104e74675193be365a7a5036be10759f006130f03b3668a87c1cd@%3Cdev.training.apache.org%3E On Mon, Mar 11, 2019 at 2:35 PM 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. > > 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 > > > > > > > > > > > > > > -- Sönke Liebau Partner Tel. +49 179 7940878 OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany
