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
> 

Attachment: signature.asc
Description: Message signed with OpenPGP

Reply via email to