> 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
