Re: On wearing multiple hats

2016-10-25 Thread Shane Curcuru
Two small comments:

Ross Gardler wrote on 10/25/16 10:19 AM:
> First, I'm tired of hearing it too but let's not be fooled, most of
> the time it comes from people ill informed about how the ASF works.
> 
> We use social controls within the projects and we have a fully
> independent board to handle escalations should a community member
> feel that their (or anothers) merit not be recognized.
> 
> If this is breaking down then its a problem within the PMC not with
> the process, which has served us well for many years across many
> projects and should, IMHO, serve us well for many more. Rather than
> starting to look for a solution to a problem purebred by others
> perhaps we should look at why they have this perception.

Part of this issue is lack of easily consumable and definitive
information on how our governance models work.  Yes, we have some public
documentation, but it's scattered, inconsistent, and much of it is not
very friendly to newcomers.  There are a lot of bits of tribal knowledge
that some of us understand intuitively, but that aren't actually written
clearly enough to communicate them broadly.

Obviously, some people won't read this stuff anyway.  But at least
having a better set of URLs that we can send out to point to our
corporate policies, user stories, or even metrics would go a long way in
making it easier for us to respond to newcomers with a consistent set of
stable information.

...snip...
> Isabel Drost-Fromm wrote on 10/25/16 3:50 AM:
...snip...
>> [5]
>>
https://lists.apache.org/thread.html/76610c48321397e7af8e2e433ac73e6e1da4aa1a80b1fac67e7ed8c2@%3Cboard.apache.org%3E

Please note that this [5] link is to a privately archived list - so many
folks here won't be able to see anything there in Pony Mail, even if you
login.

- Shane


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



Re: On wearing multiple hats

2016-10-25 Thread Sam Ruby
On Tue, Oct 25, 2016 at 3:50 AM, Isabel Drost-Fromm  wrote:
> Pre-text: This conversation started among several members of the ASF, you are
> seeing this message here, as it was suggested to have the discussion on a
> public mailing list so everyone can participate.
>
>
> Hi,
>
> tl;dr: I'm tired of hearing Apache is "where large firms dump code (to break 
> the
> market for other or to avoid looking bad for abandoning it", I'm also tired of
> hearing that Apache is where projects are controlled by corporate interests
> under the disguise of some Apache Way process. I would like to figure out
> whether this is actually true based on numbers instead of subjective
> perceptions. If it is true I would like to figure out if and how we need to 
> fix
> this.

Unfortunately, for matters like these, perception =  reality.  Facts
and figures won't easily change those perceptions.

> Longer version: Every now and then I hear people complain either privately or
> publicly [1] that people working on Apache projects who are not paid to do 
> that
> work and have don't have the luxury to participate full-time are facing a hard
> time getting into our communities.

Some projects have higher bars than others.  If the net effect of a
higher bar is to exclude those that can only afford to contribute on
their own time, then we should address that -- on a case by case
basis.

> Similarly every now and then we see projects running into trademark issues,
> conflicts of interest with their employers, trouble with wearing too many hats
> [2,3] (though everytime I hear about wearing more than one hat I have to think
> of the following lightning talk [4]).
>
> I don't think handwavery statements will get us very far. Maybe it makes sense
> to think about the following first:
>
> - If projects are making progress (getting new releases out, getting new
>   features implemented, getting bugs and security vulnerabilities addressed), 
> do
>   we care about how they are governed? Why do we care if we do? About which
>   aspects do we care?

We very much do care.

To illustrate: I work for a large company where cluefullness is not
evenly distributed.  Once (in the now distant past), a group was
referred to me for advice on how to approach the ASF.  The
conversation started with that individual expressing a desire to
control the content of the product, who was and was not allowed to
contribute, and what license the code was released under.  The
conversation ended with me saying that they don't want to come to the
ASF.

At the time, I directed them to SourceForge.  These days, I would have
suggested GitHub.

> - Given the influx of projects into the incubator (and the number of projects
>   making it through) people seem to trust the ASF as a home for their
>   communities. What kind of value does that have for us? What is the value we
>   are giving back to these projects?

>From my perspective, I see the growth as evidence that people value
our model of governance, our license, and our brand.

As for your last question, I don't see us having any obligation to
give back to those that don't value our model of governance, our
license, and our brand.

> Maybe from there we can come up with stories and metrics that hold (or should
> hold) for all of our projects.

+1 for stories
-0 for metrics

> Let me provide an example for illustration: In many previous conversations and
> talks I stressed that Apache is about communities, that being part of an 
> Apache
> project doesn't necessarily mean that the particular human has to contribute
> large amounts of code - in the case of Mahout at some point we even had to
> communicate that the best way to not be accepted as a GSoC student would be to
> propose to implement yet another machine learning algorithm as that would
> probably not what the project needed most, nor would it be feasable given the
> time frame. Based on that my answer to "do we care about how projects are
> governed" would be "yeah, sure we do - our system is based on merit, merit 
> comes
> from valuable contributions". The metric I'd setup to test that hypothesis is
> true would be to cross-check number of contributions (patches, documentation
> fixes and the like) with whether the people making these contributions are
> actually being promoted to committer. Makes sense?

Again, this varies too widely between projects to make comparison
meaningful.  Some projects give out committership like candy (I tend
to lean this way).  Others have a more rigorous definition of merit.

As a rule of thumb, if a PMC has three independent and active members,
added a PMC member within the past year, and made a release during
that time and is not reporting any problems, then generally all is
good from a board perspective.  But these are not hard and fast rules,
deviations from one or more can also be OK.  And a project can meet
these criteria and still be a problem.

Like others, I see metrics as an aid, not an end in itself. 

Re: On wearing multiple hats

2016-10-25 Thread Ross Gardler
First, I'm tired of hearing it too but let's not be fooled, most of the time it 
comes from people ill informed about how the ASF works.

We use social controls within the projects and we have a fully independent 
board to handle escalations should a community member feel that their (or 
anothers) merit not be recognized.

If this is breaking down then its a problem within the PMC not with the 
process, which has served us well for many years across many projects and 
should, IMHO, serve us well for many more. Rather than starting to look for a 
solution to a problem purebred by others perhaps we should look at why they 
have this perception.

Here's my thoughts...

Open source, in general, has changed. Its gone from mostly individual hackers 
from small collaborating companies "scratching their own itch" to mostly big 
business and will funded startups paying individuals who sometimes don't care 
on a personal level. This has resulted in the emergence of a different flavor 
of open source. One in which money and metrics count more than community and 
code. I'm the money and metrics model success means market disruption rather 
than collaboration on code.

I maintain that the Apache Way is still a highly valuable and repeatable 
process that when applied correctly brings the highest chance of success (where 
success is valuable open source code). It is a process that is designed to 
ensure that those who care on a personal level have as much influence as those 
who are motivated by external need. It is a process that leaves money and 
metrics at the door but recognizes community and code contributions quickly.

I'm not a fan of metrics. They are often misleading and allow any story to be 
told. I'm much more interested in people taking responsibility for the health 
of their community than taking the easy route and monitoring an arbitrary 
metric. Those people should be working within project PMCs to ensure all 
contributions (code or otherwise) are being recognized. They should be 
identifying new committees not a "number of commits" metric that ignores the 
individual who facilitates consensus and merit recognition on our mailing lists.

If a PMC is devoid of such individuals then it is nothing more than a shared 
code base regardless of how many new committers are brought in. Those projects 
exist, but they should not exist in the ASF where we stand for "community 
before code".

The current metric, reported quarterly, to a vendor neutral and member elected 
board is "last addition of a committer". This is good. When it goes a long time 
the board should ask "why". Sometimes its because a project is in maintenance 
mode (no problem with that) other times its because a PMC is not recognizing 
contributions and needs reminding.

Do we really need metrics? Perhaps we need more awareness in our communities 
about why building a personal profile in a project is good for both career and 
community. Then we can help people build those personal profiles by ensuring we 
recognizing all contributions that bring stability, independence and health to 
a project community.

Ross



---
Twitter: @rgardler


From: Isabel Drost-Fromm 
Sent: Tuesday, October 25, 2016 12:50:21 AM
To: dev@community.apache.org
Subject: On wearing multiple hats

Pre-text: This conversation started among several members of the ASF, you are
seeing this message here, as it was suggested to have the discussion on a
public mailing list so everyone can participate.


Hi,

tl;dr: I'm tired of hearing Apache is "where large firms dump code (to break the
market for other or to avoid looking bad for abandoning it", I'm also tired of
hearing that Apache is where projects are controlled by corporate interests
under the disguise of some Apache Way process. I would like to figure out
whether this is actually true based on numbers instead of subjective
perceptions. If it is true I would like to figure out if and how we need to fix
this.


Longer version: Every now and then I hear people complain either privately or
publicly [1] that people working on Apache projects who are not paid to do that
work and have don't have the luxury to participate full-time are facing a hard
time getting into our communities.

Similarly every now and then we see projects running into trademark issues,
conflicts of interest with their employers, trouble with wearing too many hats
[2,3] (though everytime I hear about wearing more than one hat I have to think
of the following lightning talk [4]).

I don't think handwavery statements will get us very far. Maybe it makes sense
to think about the following first:

- If projects are making progress (getting new releases out, getting new
  features implemented, getting bugs and security vulnerabilities addressed), do
  we care about how they are governed? Why do we care if we do? About which
  aspects do we care?

- Given the influx of projects into the incubator (and the number of 

Re: Addition to the project maturity model

2016-10-25 Thread Mark Thomas
On 04/10/2016 09:11, Bertrand Delacretaz wrote:
> On Tue, Oct 4, 2016 at 9:50 AM, Mark Thomas  wrote:
>> ...I'm wondering about expanding "... generate a release." to "... generate
>> the complete set of artifacts required for a release."
> 
> Works for me, it's more precise.

Done.

Mark


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



On wearing multiple hats

2016-10-25 Thread Isabel Drost-Fromm
Pre-text: This conversation started among several members of the ASF, you are
seeing this message here, as it was suggested to have the discussion on a
public mailing list so everyone can participate.


Hi,

tl;dr: I'm tired of hearing Apache is "where large firms dump code (to break the
market for other or to avoid looking bad for abandoning it", I'm also tired of
hearing that Apache is where projects are controlled by corporate interests
under the disguise of some Apache Way process. I would like to figure out
whether this is actually true based on numbers instead of subjective
perceptions. If it is true I would like to figure out if and how we need to fix
this.


Longer version: Every now and then I hear people complain either privately or
publicly [1] that people working on Apache projects who are not paid to do that
work and have don't have the luxury to participate full-time are facing a hard
time getting into our communities.

Similarly every now and then we see projects running into trademark issues,
conflicts of interest with their employers, trouble with wearing too many hats
[2,3] (though everytime I hear about wearing more than one hat I have to think
of the following lightning talk [4]).

I don't think handwavery statements will get us very far. Maybe it makes sense
to think about the following first:

- If projects are making progress (getting new releases out, getting new
  features implemented, getting bugs and security vulnerabilities addressed), do
  we care about how they are governed? Why do we care if we do? About which
  aspects do we care?

- Given the influx of projects into the incubator (and the number of projects
  making it through) people seem to trust the ASF as a home for their
  communities. What kind of value does that have for us? What is the value we
  are giving back to these projects?


Maybe from there we can come up with stories and metrics that hold (or should
hold) for all of our projects.



Let me provide an example for illustration: In many previous conversations and
talks I stressed that Apache is about communities, that being part of an Apache
project doesn't necessarily mean that the particular human has to contribute
large amounts of code - in the case of Mahout at some point we even had to
communicate that the best way to not be accepted as a GSoC student would be to
propose to implement yet another machine learning algorithm as that would
probably not what the project needed most, nor would it be feasable given the
time frame. Based on that my answer to "do we care about how projects are
governed" would be "yeah, sure we do - our system is based on merit, merit comes
from valuable contributions". The metric I'd setup to test that hypothesis is
true would be to cross-check number of contributions (patches, documentation
fixes and the like) with whether the people making these contributions are
actually being promoted to committer. Makes sense?

Anyone interested in this? Anyone interested in helping get sensible numbers up
- my JIRA magic is seriously lacking...


Isabel


[1]
http://apache-spark-developers-list.1001551.n3.nabble.com/Spark-Improvement-Proposals-tt19268.html#none

[2]
https://www.youtube.com/watch?v=F0DpP25QCfQ=PL055Epbe6d5YSf1gQ-KL68xI9QsE70oIZ=13

[3]
https://www.youtube.com/watch?v=26T-UKAs1Fk=PL055Epbe6d5YSf1gQ-KL68xI9QsE70oIZ=11

[4] https://www.flickr.com/photos/carlossg/4081471635

[5]
https://lists.apache.org/thread.html/76610c48321397e7af8e2e433ac73e6e1da4aa1a80b1fac67e7ed8c2@%3Cboard.apache.org%3E

-- 
Sorry for any typos: Mail was typed in vim, written in mutt, via ssh (most 
likely involving some kind of mobile connection only.)

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