Hi - Having started on a project as such a “Management" person ….
> 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; > > How fast could an individual expect to be given the authority to do this > type of project management, without contributing a line of code? It depends on the project. The place to start is by contributing to discussions on the dev@ and/or user@ lists in order to get recognized. If there are developers from $DayJob on the PPMC they with the rest of the PPMC can determine when they get these people involved with rights. Apache projects require a flat, meritocracy and these PM need to earn the right within the Project. That right then is theirs whether or not they remain employed by $BigCo. If having commit rights on GitHub is a problem then the project can use a Wiki (MoinMoin or Confluence) and/or an Issue Tracker (JIRA or Bugzilla). The project should not be surprised as the developers should be communicating about what they are developing. This is Open Source Development … do it in public and be happily surprised when unexpected people show up with contributions. Grow a true community. Regards, Dave > > Ralph wrote: > >> Companies do not do the prioritization, planning, road-mapping, > shaping product-design, etc of ASF projects. The committers and PMC > members do that. > > Most of the companies that have a person whose sole duty is to manage > employees that work on a specific open source project, will ignore > upstream requests, if they don't have access to do management things > there. This will result in undesirable surprises. > > If the company PM does have access at the Open Source Project level, > then the input from the other contributors will be taken into consideration. > > Yes, there is a very fine line to walk, between allowing a company > position authority to do "x", and preventing the company from taking > over the project. > >> They can use their own Jira repo for that kind of stuff. > > 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? > > jonathon > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org >
Description: Message signed with OpenPGP