1. Very much so. In Airflow we defined some criteria for becoming committers and we separated out "code" and "community" contributions to make it clear. https://github.com/apache/airflow/blob/master/COMMITTERS.rst#code-contribution Also what we made clear there that there are no "code/community" contributors. You can do (and best if you do) both :).
2) I think this is a dangerous path to take. I think one of the important aspects of Apache projects is how easy and friction-less it is to become a contributor. Signing an ICLA can be very easily abused by "owners" of the software to make it not really and truly open-source in spirit. There was this interesting picture https://twitter.com/higrys/status/1389979584737779717 which sparked some short discussion about it. And while I agree Apache ICLA Is "fine", there are a lot of people who treat any attempt to ask them to sign ICLA with default "no" or "i am not going to read all those legal-speak" or "probably they want to trick me into something". And for a good reason, because in many cases those ICLAs might actually have some "interesting" clauses. I think if we ask people before they are invited to become committers to sign the ICLA, this goes against this "frictionless" approach and it immediately raises many questions: * what is the criteria deciding when we ask ? * what happens if the contributor refuses? * what do we answer if the contributor asks why we need it? I think the current approach where ICLA MUST be signed in order to become a committer is great. With great powers come great responsibilities, and it makes perfect sense that the ICLA should be signed then. I see no reason why we should make the "committer" approval simpler. It brings no benefits other than a couple of days delay and IMHO, inviting a committer is a thing that SHOULD look serious and should be involving additional action from the new committer-to-do. This makes sure that the new committer is aware about the new powers/responsibilities coming with it. Side comment: If some projects have a very high bar to become committers, maybe they should lower the bar rather than ask for ICLA from their contributors ? J. On Sun, May 9, 2021 at 2:58 AM Craig Russell <apache....@gmail.com> wrote: > Hi, > > Looking at How it Works, I think it needs an update to reflect current > thinking on community. > > 1. https://www.apache.org/foundation/how-it-works.html#developers > > I believe there is consensus that contributors are not only developers > with their hands on the code, but: > people who ask and answer questions on the user and dev lists; > people who find bugs and report them, with or without writing test cases; > people who document the projects, including web and "hard copy" documents; > people who help organize meetups, both in real life and online. > > So perhaps we could add a section on "contributors" that covers the other > categories of non-developer contributors? > > 2. I believe that we should ask contributors for an ICLA long before they > are invited to become committers. > > Once a contributor has made several non-trivial contributions to a > project, I believe that the project should ask them to file an ICLA if they > have not already done so. This will have these potential benefits: > > It will be much easier to make them committers; all it will take is for > the PMC to hold a successful vote and as soon as they are invited and > accept, the PMC can simply request their account. > > It will give the PMC incentive to communicate with their contributors > about the value the contributors bring to the projects. Our increasing use > of GitHub for development makes this a straightforward exercise. Each PMC > will have their own criteria for asking for an ICLA, which doubtless will > be less stringent than committership. > > It will clarify the intellectual property issues (provenance) associated > with the contributions. Some projects have a very high bar for > committership and all of the contributions prior to formal offers of > committership are assumed to be given under the terms of the Apache > License, but we have no formal understanding of this. > > Craig > > Craig L Russell > c...@apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > > -- +48 660 796 129