> On Apr 16, 2018, at 4:22 PM, toki <toki.kant...@gmail.com> wrote:
> 
> On 04/16/2018 07:37 PM, Ralph Goers wrote:
>> IMO, it is inappropriate to add project managers to a project as a committer 
>> just because they are employed by a company that has committers who are paid 
>> to work on the project.
> 
> There are some companies who have a person whose sole duty is manage the
> employees that work on a specific open source project.
> 
> As such, open source projects have two options:
> * grant the employee position the access needed to manage the project,
> so that everybody can see what is going on;
> * deny the employ position the needed access, and be surprised by what
> the company contributes. In most instances, the surprises are things
> that were neither anticipated, nor considered needed by the non-employee
> contributors;

The implication with the way this is all being stated is that the project 
manager is making the decisions about everything and everyone is marching to 
his orders. That is just not how the ASF is supposed to operate.  It is the 
PMC’s job, as a group of collaborators, to make these decisions. That said, 
there is no reason the PMC can’t allow project managers (or anyone else) to 
make proposals regarding a roadmap using Confluence, so long as they are 
discussed and approved by the PMC. The project manager is then free to create 
Jira issues that align with the roadmap. However, what if a committer who 
doesn’t work for the same company as the project manager wants to implement one 
of the roadmap features and/or has different ideas about how it should be done? 
It is up to the PMC as a whole to resolve that, not any one individual.

What you are missing above is the third option. Grant them access to Jira and 
Confluence. Then have them discuss what they are doing on the mailing list. The 
basic difference here is that the individual is not “running” the project but 
is instead contributing to it. If,  after the merit is earned, the PMC decides 
to grant commit rights and/or make them a PMC member, then great. That is how 
it is supposed to work.

The point of all this is, the ASF isn’t trying to get in the way of anyone 
doing their job. Instead, it is trying to put each individual on an equal 
footing with everyone else. Sometimes this may get in the way of a company’s 
goals, but if they wanted to keep total control of the project then they 
shouldn’t have contributed it to the ASF.

>> 
> 
> Do you really want to see a build of, say, Apache OpenOffice, with
> complete L10N (Help documentation, UI, grammar checking, spell checking
> for both ancient, medieval, and modern forms of the official
> language(s), and writing system(s), etc.) for say, Crimea, North Korea,
> or Syria, with no prior notice, much less discussion. I have a pretty
> good idea of what ASF-Legal will say about that specific scenario.
> 
> Sure the company can just fork the project. It has happened before, and
> it will happen again. But setting up conditions where forking is the
> only option for a community based project is, IMNSHO, non-viable.
> 
>> such people can earn merit by becoming involved with the community and
> helping out where they can.
> 
> In theory, that sounds good, but as a practical matter, how many people
> that have ever been on the ASF board of directors neither know/knew, nor
> use(d) any programming languages in getting there? IOW, they got there
> exclusively on their ability to write documentation, do community
> relations, or utilize other non-coding skills?

It has happened many times. When I was a committer on Apache Cocoon we voted 
Arje Cahn as a committer for his contributions to the project which had nothing 
to do with coding. He was voted in as an ASF member for pretty much the same 
reason.

Ralph



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Reply via email to