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 :-). Kenn > > > > > Thanks, > > Justin > > > > 1. https://wiki.apache.org/incubator/DefaultProjectGuidelines >
