HI,
> Recently I tried to propose a guideline to MXNet community to encourage
> PMC members to propose committers that comes from different organizations
> that they come from.
It shouldn't matter at all who a potential committer works for, their merit is
gained by what they do as an
Dear Incubator General:
I am writing this email to seek your experience on how do you try to
encourage diversity in your community and encourage collaboration among
contributors across organizations. One of the key driving force of Apache
is its neural nature which encourages collaboration
There was a private thread started around the infra related feedback from
the "Committer Diversity Survey", and it was summarized by one of our
colleagues as: GitHub, GitHub, GitHub, GitHub
I would like to bring my perspective around this, as I don't think it's
about GitHub, GitH
. The project
must be open, and not threatened by the challenges that open
development poses. We encourage transparency by creating a climate for
projects to report honestly about diversity, rather than incentivizing
corruption of that metric.
As this thread demonstrates, the IPMC cannot do more
on it.
But as it stand, the policy states that for a project to be considered
for graduation, it shall demonstrate diversity, and people are in their
right to raise that as a concern, as it is _in the policy_, regardless
of what a segment of the IPMC have decided in other graduation
discussions or votes
On 6 June 2012 03:46, Sam Ruby ru...@intertwingly.net wrote:
On Tue, Jun 5, 2012 at 8:00 PM, Roy T. Fielding field...@gbiv.com wrote:
There is no diversity requirement at the ASF.
On one hand, I definitely agree with you. Derby graduated without
meeting the diversity requirement
On Jun 5, 2012, at 2:45 PM, Ralph Goers wrote:
I posted an email earlier today where I discussed my confusion over the
diversity requirement. I'm not comfortable doing anything without getting
some feedback on whether the diversity requirement, as currently stated on
the wiki, is correct
The diversity (so-called) requirement is often stated in terms of the
risk of the project being stranded if a company changes course. From
what I see around the Foundation, this is usually a risk much akin to
the risk of all the air molecules congregating in one corner of the
room at the board F2F
. Neither
does our brand. Let's please stop pretending it does.
+1 to Roy's and Benson's remarks
- Original Message -
From: Benson Margulies bimargul...@gmail.com
To: general@incubator.apache.org
Cc:
Sent: Tuesday, June 5, 2012 8:24 PM
Subject: Re: diversity
T he diversity (so-called
Thanks Roy. Yes, I would like the diversity section modified, although I'm not
quite sure how I'd reword it. Even if it isn't, your post below can always be
referenced again to aid anyone else who may be confused.
Ralph
On Jun 5, 2012, at 5:00 PM, Roy T. Fielding field...@gbiv.com wrote
On Tue, Jun 5, 2012 at 8:00 PM, Roy T. Fielding field...@gbiv.com wrote:
There is no diversity requirement at the ASF.
On one hand, I definitely agree with you. Derby graduated without
meeting the diversity requirement.
That being said, I would like to bring up one thing: I have found
Hi,
On Thu, Aug 6, 2009 at 5:16 AM, Niclas Hedhmannic...@hedhman.org wrote:
Would it make a difference, if I step up and make the initial PMC Chair, as
I have over the last couple of weeks started my own commitment to the
project?
My main concern is over the small number of people writing
certainly good, but [snip]
...
Besides all the other good things diversity brings it's also an
insurance policy for the project, and that's what I think the
Incubator should be looking for as a graduation criteria.
You are trying to predict the future. Good luck with that.
...
From my
Hi,
On Wed, Aug 5, 2009 at 3:39 AM, Ralph Goersralph.go...@dslextreme.com wrote:
Using these projects as an example is perhaps not the best from a community
perspective because Ceki has no intention of running them like Apache
projects. But even if he did, by these standards the projects might
Jukka Zitting wrote:
Hi,
On Wed, Aug 5, 2009 at 3:39 AM, Ralph Goersralph.go...@dslextreme.com wrote:
Using these projects as an example is perhaps not the best from a community
perspective because Ceki has no intention of running them like Apache
projects. But even if he did, by these
On Aug 5, 2009, at 2:00 AM, Jukka Zitting wrote:
Hi,
On Wed, Aug 5, 2009 at 3:39 AM, Ralph
Goersralph.go...@dslextreme.com wrote:
Using these projects as an example is perhaps not the best from a
community
perspective because Ceki has no intention of running them like Apache
projects.
On Aug 5, 2009, at 8:21 AM, Ralph Goers wrote:
On Aug 5, 2009, at 2:00 AM, Jukka Zitting wrote:
Hi,
On Wed, Aug 5, 2009 at 3:39 AM, Ralph Goersralph.go...@dslextreme.com
wrote:
Using these projects as an example is perhaps not the best from a
community
perspective because Ceki has no
Hi,
On Wed, Aug 5, 2009 at 5:21 PM, Ralph Goersralph.go...@dslextreme.com wrote:
You won't find the second part solely from the commit log. I would expect
mentors to be monitoring the dev list. If it is filled with can you fix
this? then there is a problem. But if it also has why did you do
On Aug 5, 2009, at 8:40 AM, Jukka Zitting wrote:
Hi,
On Wed, Aug 5, 2009 at 5:21 PM, Ralph
Goersralph.go...@dslextreme.com wrote:
You won't find the second part solely from the commit log. I would
expect
mentors to be monitoring the dev list. If it is filled with can
you fix
this? then
Hi,
On Wed, Aug 5, 2009 at 6:02 PM, Ralph Goersralph.go...@dslextreme.com wrote:
On Aug 5, 2009, at 8:40 AM, Jukka Zitting wrote:
We are looking for projects with at least three independent
committers, and personally I'm not including inactive committers in
that count.
Now you are making
On Wed, Aug 5, 2009 at 4:32 PM, Ralph Goersralph.go...@dslextreme.com wrote:
On Aug 5, 2009, at 8:21 AM, Ralph Goers wrote:
On Aug 5, 2009, at 2:00 AM, Jukka Zitting wrote:
Hi,
On Wed, Aug 5, 2009 at 3:39 AM, Ralph Goersralph.go...@dslextreme.com
snip
That's why I measure the three
AFAIK Nowhere in the policy it is stated that committer activity ==
code commits.
Martijn
On Wednesday, August 5, 2009, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
On Wed, Aug 5, 2009 at 6:02 PM, Ralph Goersralph.go...@dslextreme.com wrote:
On Aug 5, 2009, at 8:40 AM, Jukka Zitting
Hi,
On Wed, Aug 5, 2009 at 6:58 PM, Martijn
Dashorstmartijn.dasho...@gmail.com wrote:
AFAIK Nowhere in the policy it is stated that committer activity ==
code commits.
True, but that's how I interpret it, for reasons stated earlier in this thread.
My -1 in the Pivot vote is just a statement
On Aug 5, 2009, at 9:58 AM, Martijn Dashorst wrote:
AFAIK Nowhere in the policy it is stated that committer activity ==
code commits.
Martijn
Absolutely right. I'd actually like to see more than 3 people with
commit privs (and I think most projects have that). As a mentor I
would be
and
River is showing some positive signs, but both cases have required
(and still require) quite a bit of mentoring to get them going again.
Besides all the other good things diversity brings it's also an
insurance policy for the project, and that's what I think the
Incubator should be looking
On Aug 5, 2009, at 2:44 PM, Niall Pemberton wrote:
OK we have a similar example here at the ASF - when Craig McC. left
Apache Shale it slowly died - and AFAIK become the first project to
join the Attic. So Ceki decides to become a Yak farmer in patagonia
and maybe the same thing happens to
On Aug 5, 2009, at 10:15 AM, Jukka Zitting wrote:
Hi,
On Wed, Aug 5, 2009 at 6:58 PM, Martijn
Dashorstmartijn.dasho...@gmail.com wrote:
AFAIK Nowhere in the policy it is stated that committer activity ==
code commits.
True, but that's how I interpret it, for reasons stated earlier in
I will try to answer it;
1. I think it is an extreme question. If both disappeared tomorrow, I don't
think the will to continue exists. If it happens 12 months from now in the
Incubator, I think it could go either way. If happens 12 months after
graduation, I am pretty sure it sustains. Why do I
Jukka,
I don't like to force majority result if there is controversy.
Having a couple of -1, and other not voting but practically agreeing with
you and Ant, is not the way to go.
I think they are as ready as they can get, considering the starting point
and the general attitude towards incubated
all the other good things diversity brings it's also an
insurance policy for the project, and that's what I think the
Incubator should be looking for as a graduation criteria.
BR,
Jukka Zitting
-
To unsubscribe, e-mail: general
a bit of mentoring to get them going again.
Besides all the other good things diversity brings it's also an
insurance policy for the project, and that's what I think the
Incubator should be looking for as a graduation criteria.
You are trying to predict the future. Good luck
Yes,
And here is another angle; ALL projects will die, it is just a matter of
time.
Now, knowing that we need to deal with, and can't set out with the notion
that if we think it might whither it can't graduate, then I will need to
vote against all graduations.
So, IMHO, the might die criteria is
Hi Craig,
snip
One thing that would help, especially in the case of qpid, is to document
whether the committers feel that they are independent. That is, whether they
would continue to contribute to the project on their own time even if their
employer reassigned them to a different project.
This
Meant to add that I'm feeling a chill over the idea of more docs here, so
I'll be off back to Qpid and poll our mentors instead :-)
Thanks Niclas Craig,
Marnie
On Mon, Sep 29, 2008 at 1:18 PM, Marnie McCormack
[EMAIL PROTECTED] wrote:
Hi Craig,
snip
One thing that would help, especially
On Sun, Sep 28, 2008 at 6:28 AM, Craig L Russell [EMAIL PROTECTED] wrote:
...One thing that would help, especially in the case of qpid, is to document
whether the committers feel that they are independent. That is, whether they
would continue to contribute to the project on their own time even
Hi Niclas,
On Sep 23, 2008, at 8:28 PM, Niclas Hedhman wrote:
As for more documentation; I am -0 on that, but I guess Craig and
Martijn
will probably jump at the opportunity ;o)
Well, thanks but no thanks. ;-)
My views are similar to yours. Diversity is a subjective thing, and
every
AM, Niclas Hedhman [EMAIL PROTECTED] wrote:
On Tue, Sep 23, 2008 at 11:45 PM, Marnie McCormack
[EMAIL PROTECTED] wrote:
Hi All,
Some of you with long memories may recall previous threads about project
diversity.
At the end of one such debate, I put forward some ideas about what
Hi All,
Some of you with long memories may recall previous threads about project
diversity.
At the end of one such debate, I put forward some ideas about what items
might benefit from some good practice guidelines (see below).
My special interest is Qpid, as I'll happy submit
On Tue, Sep 23, 2008 at 11:45 PM, Marnie McCormack
[EMAIL PROTECTED] wrote:
Hi All,
Some of you with long memories may recall previous threads about project
diversity.
At the end of one such debate, I put forward some ideas about what items
might benefit from some good practice guidelines
and is responsible enough to sustain itself
as such a community.
It's just that to an outsider, it is totally unclear what that
means. And it may be impossible to really convey the meaning
of it in a few sentences. So why don't we just say so.
Make it absolutely clear that the diversity
Thilo Goetz wrote:
It's just that to an outsider, it is totally unclear what that
means. And it may be impossible to really convey the meaning
of it in a few sentences. So why don't we just say so.
Make it absolutely clear that the diversity of the community
will be judged by the IPMC based
On Thu, Mar 27, 2008 at 5:55 AM, Endre Stølsvik [EMAIL PROTECTED] wrote:
Thilo Goetz wrote:
Make it absolutely clear that the diversity of the community
will be judged by the IPMC based on the overall conduct of the
One obvious problem with such approaches is that the criteria
Endre Stølsvik wrote:
Thilo Goetz wrote:
Make it absolutely clear that the diversity of the community
will be judged by the IPMC based on the overall conduct of
the project, mailing list, commit activity etc.
I'm not sure that diversity and conduct are really mapping that way. A
non
Noel J. Bergman wrote:
Endre Stølsvik wrote:
Thilo Goetz wrote:
Make it absolutely clear that the diversity of the community
will be judged by the IPMC based on the overall conduct of
the project, mailing list, commit activity etc.
I'm not sure that diversity and conduct are really mapping
than general
committer composition on a project and thus we should strive to make it
diverse by encouraging (nominating) committers on to the PMC for diversity
reasons ?
- Code vs documentation weighting. Some projects have contributers
whose focus is specialised in a particular area
Hi,
We've already discussed this a bit in the past [1][2][3] but no clear
consensus as emerged with respect to diversity and the current graduation
policy. There seems to be growing pain with the following policy paragraph
in the graduation checklist:
The project is not highly dependent on any
I think this is an important topic for future incubator project groups
to have clarified.
The project is not highly dependent on any single contributor (there are at
least 3 legally independent committers and there is no single company or
entity that is vital to the success of the project)
On Wed, Mar 26, 2008 at 5:03 PM, Robert Greig [EMAIL PROTECTED]
wrote:
I think this is an important topic for future incubator project groups
to have clarified.
The project is not highly dependent on any single contributor (there
are at
least 3 legally independent committers and there is
Another point that needs discussion and more clarification is related
to who should be counted towards diversity of a project. From [1], it
states that a podling need at least 3 legally independent committers,
but from recent comments on the QPid graduation thread [2], it seems
that only PMC
the above should provide enough information about the health and
diversity of the community that actually working on the code.
What is the Qpid community's response to these findings?
--- Noel
Ok I have a few comments in response to the findings:
- Firstly not all work
On Sat, Mar 8, 2008 at 7:03 AM, Niclas Hedhman [EMAIL PROTECTED] wrote:
On Friday 07 March 2008 03:04, Daniel Kulp wrote:
That all said, I'm NOT on the IPMC. Thus, my thoughts don't really
count other than to provide insight based on MY experiences. I don't
have a binding vote.
But
, we're ready to go! but
Jim (one of our mentors) still had concerns about diversity. Thus, we
stuck with it and worked hard on getting other people more involved.
It has paid off as we have added several very good folks that have
brought fresh ideas and perspectives to the project. If we HAD
On Mar 7, 2008, at 11:07 PM, Niclas Hedhman wrote:
On Friday 07 March 2008 16:39, William A. Rowe, Jr. wrote:
So the CCLA exists for those who's employment agreements would
otherwise
cause them to violate their claims made via their CLA contract.
Uhhh So, are we now saying that heaps of
Scott Deboy wrote:
Does ASF need proof that a transfer of intellectual property ownership
occurred?
In your CLA - you attest that you have that right. If you don't - it's
on you to remedy it. The ASF doesn't broker relationships between
developers and their employers, clients, or spouses :)
On Friday 07 March 2008 03:04, Daniel Kulp wrote:
That all said, I'm NOT on the IPMC. Thus, my thoughts don't really
count other than to provide insight based on MY experiences. I don't
have a binding vote.
But your view is highly appreciated.
Cheers
--
Niclas Hedhman, Software Developer
about the health and
diversity of the community that actually working on the code.
What is the Qpid community's response to these findings?
--- Noel
Ok I have a few comments in response to the findings:
- Firstly not all work is done on trunk so purely looking at trunk
) I would
completely ignore these people as adding to the 'diversity' and in
fact advise to assume the 'worst' - and treat them as one block.
I.e. they are _counter_ to the diversity you want to show.
That is the most robust approach. As information leaks
to RedHat
employees.
I think the above should provide enough information about the health
and
diversity of the community that actually working on the code.
What is the Qpid community's response to these findings?
--- Noel
I believe if a committer has signed
: Thursday, March 06, 2008 10:48 AM
To: general@incubator.apache.org
Subject: Re: FW: (qpid) Diversity
On Thu, Mar 6, 2008 at 8:23 AM, Martin Ritchie [EMAIL PROTECTED]
wrote:
On 06/03/2008, Noel J. Bergman [EMAIL PROTECTED] wrote:
Daniel Kulp write:
a quick svn log on their SVN repo for all
to know more about are trends. Is the community
getting better or worse from a diversity standpoint. That IS
subjective to some extent and each IPMC member may interpret the data
differently, but the point is they need the data.Thus, having the 6
month, 4 month, and 2 month numbers
Does ASF need proof that a transfer of intellectual property ownership
occurred?
Scott Deboy
-Original Message-
From: Robert Greig [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 06, 2008 3:10 PM
To: [EMAIL PROTECTED]; general@incubator.apache.org
Subject: Re: FW: (qpid) Diversity
On 06/03/2008, Scott Deboy [EMAIL PROTECTED] wrote:
For the qpid folks who don't want to divulge their employer: are they
working on the project as part of their employment? If so, it would
appear we need a CCLA, correct?
I do not believe so since those employees have signed legal documents
All,
Several of our project (Qpid) memebers are legally in a difficult position
disclosing their employer in Apache world. They have signed a legal
document, in order to be allowed to contribute to Apache, and thus this is
not a simple preference issue.
Regards,
Marnie
On 3/5/08, Carl Trieloff
anonymously?
e.g.
Company 1 employs Adrian, Barbara, Cedric
Company 2 employs Peter, Quentin, Rick
This might help with determining diversity.
They have signed a legal
document, in order to be allowed to contribute to Apache, and thus this is
not a simple preference issue.
My own
Another option would be to not consider the people that cannot disclose
their employers when considering the diversity of the project. If
there are 15 people, and 5 cannot disclose their employer, only consider
the diversity of the remaining people.
Kind of the err on the side of caution
companies anonymously?
e.g.
Company 1 employs Adrian, Barbara, Cedric
Company 2 employs Peter, Quentin, Rick
This might help with determining diversity.
This could work,
Carl.
Marnie McCormack wrote:
Several of our project (Qpid) memebers are legally in a difficult position
disclosing their employer in Apache world. They have signed a legal
document, in order to be allowed to contribute to Apache, and thus this is
not a simple preference issue.
Mind you, they are
Roland Weber wrote:
If contributing to the project is part of their job responsibilities,
they should be required to disclose the employer.
That has not been made a stringent requirement, but see my response to
Melanie for what *is* a requirement.
--- Noel
Daniel Kulp write:
a quick svn log on their SVN repo for all commits since Jan 1 [suggests
that]
all but 4 commits since Jan 1 can easily be contributed to RedHat
employees.
I think the above should provide enough information about the health and
diversity of the community that actually
preference issue.
Two thoughts:
1. As to avoid having trust or distrust affecting the community
(i.e. some rot setting in at a later stage) I would
completely ignore these people as adding to the 'diversity' and in
fact advise to assume the 'worst' - and treat them as one
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Carl,
Do they *all* have CCLA's?
- -- dims
Scott Deboy wrote:
| I'm curious what other incubator folks think about qpid's plan for disclosing
the organizational diversity of their
committership/PMC (or if this is even a requirement).
|
| Scott
Davanum Srinivas wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Carl,
Do they *all* have CCLA's?
absolutely.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On Nov 18, 2007 12:46 AM, Bertrand Delacretaz [EMAIL PROTECTED] wrote:
...Here's an attempt to summarize our recent discussions, and suggest
some actions. Comments are welcome, of course
Just want to note that I have not forgotten about these discussions,
just didn't have time yet to
On Nov 23, 2007, at 3:10 AM, ant elder wrote:
Ask people to self nominate - I imagine often inactive commiters
won't
put themselves forward, removing any issue. Then maybe a review of
the
list by the the mentors and proposed PMC Chair. If there are issues
it
can be discussed in the
On Nov 22, 2007 7:09 PM, Niall Pemberton [EMAIL PROTECTED] wrote:
On Nov 20, 2007 9:14 PM, Eelco Hillenius [EMAIL PROTECTED]
wrote:
I would agree with reviewing committers at graduation, but how do we
implement that?
I would say that this depends on the judgment of the mentors, and it
On Nov 23, 2007 9:10 AM, ant elder [EMAIL PROTECTED] wrote:
On Nov 22, 2007 7:09 PM, Niall Pemberton [EMAIL PROTECTED] wrote:
Ask people to self nominate
That sounds reasonable but is it ok to do that? Its quite hard to remove a
committer from a real Apache project, are incubating
On Nov 20, 2007 9:14 PM, Eelco Hillenius [EMAIL PROTECTED] wrote:
I would agree with reviewing committers at graduation, but how do we
implement that?
I would say that this depends on the judgment of the mentors, and it
is probably more important to evaluate the role they would be playing
Ask people to self nominate - I imagine often inactive commiters won't
put themselves forward, removing any issue. Then maybe a review of the
list by the the mentors and proposed PMC Chair. If there are issues it
can be discussed in the community and if theres disagreement then
vote. I
Btw would people have interest in a small script that would analyze a
given
project history and give stats on commits and who committed? I've built
something similar for infra [1] and such reports could be useful to the
IPMC
when a podling starts talking about graduation. I'm not sure how
On Nov 22, 2007 8:09 PM, Niall Pemberton [EMAIL PROTECTED] wrote:
...Or re-elect all committers before graduation?...
...Ask people to self nominate...
Good idea, that's probably the easiest way of addressing that concern.
-Bertrand
On Nov 19, 2007 8:05 PM, Craig L Russell [EMAIL PROTECTED] wrote:
...Some of the discussion here to me seems to be backward: adding
constraints to the entry of a podling to the incubator...
Agreed, we shouldn't add more constraints than needed.
...A couple of additional comments below...
I would agree with reviewing committers at graduation, but how do we
implement that?
I would say that this depends on the judgment of the mentors, and it
is probably more important to evaluate the role they would be playing
in the project once it is over to Apache, than what happened before
...
That could be an option...but, and also taking into account remarks
made by others in this thread, that could lead to too complicated
rules. Not sure if we want to go that route.
...I also think that the diversity should be discussed during the proposal
period. If it is found to be an unbalanced
On 11/19/07, Bertrand Delacretaz [EMAIL PROTECTED] wrote:
I like the idea: discuss initial diversity among the Incubator PMC,
when a new project comes in, with the option of limiting the number of
initial non-ASF committers. But no hard rules on that.
This might be easier to implement than
Hi,
On Nov 18, 2007 1:46 AM, Bertrand Delacretaz [EMAIL PROTECTED] wrote:
3) Limit the number of new non-ASF initial committers for incubating projects
People who were not ASF committers but come in via a newly incubating
project do not get their commit rights via the normal ASF meritocracy
Same here. I think a good way to address the short way to committership
problem is to make sure people really committed consistently during the
lifetime of the poddling when the project effectively graduates.
There's something to say for that, though I think you should take
activity on the
On Nov 19, 2007 10:23 AM, Eelco Hillenius [EMAIL PROTECTED] wrote:
Same here. I think a good way to address the short way to
committership
problem is to make sure people really committed consistently during the
lifetime of the poddling when the project effectively graduates.
There's
diversity and openness. It may be quite time-
consuming, if possible at all, to try to analyze a proposed podling's
alignment with Apache's values, especially if the only metrics we
have are the proposed podling's committer list.
During incubation, diversity and openness have to be evaluated to see
to promote diversity and openness. It may be quite
time-consuming, if possible at all, to try to analyze a proposed
podling's alignment with Apache's values, especially if the only metrics
we have are the proposed podling's committer list.
During incubation, diversity and openness have
that
this is the case and would open the door for existing projects that are
already established as an open *and* diverse community.
No public mailinglists? no 'short cut'.
I also think that the diversity should be discussed during the proposal
period. If it is found to be an unbalanced community
Hi,
Here's an attempt to summarize our recent discussions, and suggest
some actions. Comments are welcome, of course.
1) We need better tools for Incubator PMC members to measure the
community diversity of incubating projects, especially before
graduation.
Suggestion:
-Require a community
3) Limit the number of new non-ASF initial committers for incubating projects
People who were not ASF committers but come in via a newly incubating
project do not get their commit rights via the normal ASF meritocracy
rules.
We might want to limit the number of such commiters, to limit the
@incubator.apache.org
To
general@incubator.apache.org
cc
Subject
Re: [DISCUSS] Community diversity: current concerns and suggestions for
improvement
3) Limit the number of new non-ASF initial committers for incubating
projects
People who were not ASF committers but come in via a newly
agree...
Do we want to set a limit on N, to give the project more
chances to reach the necessary diversity?
... but a hard number is probably a bad idea. It depends on so many factors.
The graduation committer list is more important, and since we have not figure
that one out (or have I missed
On Wednesday 31 October 2007 12:30, Matt Hogstrom wrote:
I know on Geronimo, and i suspect other projects as well,
that there have been many times that people that worked for the same
company voted differently so I don't think its totally pointless but I
understand the concern.
I would
to reach the necessary diversity?
To be honest, I think this is not the major issue. I think the major issue
is if CorporateX pulls out of a project, can it survive. Now I admit, if
CorporateX has made 99% of commits, then its going to be hard. However, if
we explicitly try to *limit* participation
, with the project's mentors having their say.
It does make it harder for those people excluded from the initial list
to enter the project, but not harder than for any other potential
committer. So I would think that's fair, and that might help community
diversity in incubating projects, even if that means
the normal way, with the project's mentors having their say.
It does make it harder for those people excluded from the initial list
to enter the project, but not harder than for any other potential
committer. So I would think that's fair, and that might help community
diversity in incubating projects
On Oct 31, 2007, at 8:38 AM, Paul Fremantle wrote:
Bertrand
Sorry - I misunderstood your point. I would be very happy to limit the
number of INITIAL committers! Yes +1.
If it makes sense to do so, then +1. But to do so just to
create a mistaken impression that the podling is, *at this
about the corporate culture of an existing group of
folk
to say they can speak independently of their employer, and honestly, we
don't
care as long as there is sufficient diversity on the project in the first
place.
Bill
1 - 100 of 116 matches
Mail list logo
