Home » Archived » Board committer reps » Project diversity
|
| Re: Project diversity [message #8849 is a reply to message #8835] |
Wed, 12 September 2007 12:41   |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------040408020006050406040307
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Scott,
I did comment on it in the blog. Here are the references from the
development process to which Bjorn is referring.
/2.5 Three Communities/
/Essential to the Purposes of the Eclipse Foundation is the
development of three inter-related communities around each Project: /
* /*Contributors* and *Committers* - a thriving, diverse and
active community of developers is the key component of any
Eclipse Project. Ideally, this community should be an open,
transparent, inclusive, and diverse community of Committers
and (non-Committer) Contributors. Attracting new Contributors
and Committers to an open source project is time consuming and
requires active recruiting, not just passive "openness". The
Project Leadership must make reasonable efforts to encourage
and nurture promising new Contributors. /
o / Projects must have the diversity goals to ensure
diversity of thought and avoiding relying on any one
company or organization. At the same time, we
acknowledge that enforcing a particular diversity metric
is a poor way to achieve these goals; rather we expect
the project leadership to help the diversity evolve
organically. /
o / Diversity is a means to an end, not an end in itself,
thus diversity goals will differ by project based on the
other accomplishments of the project(s). /
o / Project are required to explain their diversity
efforts and accomplishments during Reviews.
/
/6.3 Reviews/
/<...>/
/The criteria for the successful completion of each type of Review
will be documented in writing by the EMO in guidelines made
available via the www.eclipse.org website. Such guidelines will
include, but are not limited to the following:/
1. / Clear evidence that the project has vibrant committer,
adopter and user communities as appropriate for the type of
Review. /
2. / Reasonable diversity in its committer population as
appropriate for the type of Review. Diversity status must be
provided not only as number of people/companies, but also in
terms of effort provided by those people/companies. /
/6.3.2 Graduation Review/
/<...>/
o / active and sufficiently diverse communities: adopters,
developers, and users/
Bjorn interprets theses as requiring diversity and argues that these
requirements are not enforced. And then he argues that unenforced
requirements weaken all requirements and hence we should eliminate
unenforced requirements. There is certainly wisdom in this attitude of
eliminating rules that aren't followed nor enforced. Originally I had
thought he was just flame baiting us, but Bjorn wouldn't do that! :-p
The thing is, I don't read those rules as strictly requiring diversity
but rather as recognizing that diversity is extremely important and
something we should always keep in the forefront of our thinking. When
diversity is lacking, it should be explained and efforts to improve it
should be taken, but I think that's exactly what the verbiage above is
saying. The recent fiasco with VE where folks trying to provide a Europa
compatible version find themselves unable to make progress because there
is effectively no active committer community willing or able to commit
the changes is an excellent example of the worst that can happen. So
I'm dead set against removing any of the diversity language from the
development process.
Looking at the issue as it relates more directly to my own project(s)
with EMFT as an example, that project has a number of components that
have a very small set of committers, often just one. So while the
project has a whole is certainly diverse by any standard of diversity,
individual components are typically not, and even that could ultimately
lead to problems. But I'm not the diversity fairy with a pretty wand
that I can use to magically bestow diversity on others. (Doesn't that
conjure up an ugly picture!) It's important to note too that the
community is far more likely to take on the role of a harsh critic than
the role of a contributor, with like a 10 to 1 ratio. And the truly
saddest thing of all is the chicken and the egg problem of having such a
small committer base that properly handling contributions is inhibited.
An excellent example of this is
https://bugs.eclipse.org/bugs/show_bug.cgi?id=75625 which in my opinion
is the single most useful thing we could do for EMF in the next release,
but which other priorities are preventing us from handling with the kind
of speed that I think it deserves; it may be a couple of months at least
before us committers can set aside time to focus on this. :-(
We'll be sure to bring up the diversity issue, and VE in particular, as
part of our committer issues segment of the coming board meeting.
Scott Lewis wrote:
> I understand there there is a f2f Board meeting coming up on Sept 19,
> and I was wondering about the committer reps thinking WRT the recent
> blogging WRT project diversity:
>
> e.g. Bjorn's blog entry:
>
> http://eclipse-projects.blogspot.com/2007/09/diversity-just- lip-service.html
>
>
> Thanksinadvance for your efforts.
--------------040408020006050406040307
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Scott,<br>
<br>
I did comment on it in the blog. Here are the references from the
development process to which Bjorn is referring.<br>
<blockquote>
<h2><i>2.5 Three Communities</i></h2>
<i>Essential to the Purposes of the Eclipse Foundation is the
development of three inter-related communities around each Project:
</i>
<ul>
<li> <i><b>Contributors</b> and <b>Committers</b> - a thriving,
diverse and active community of developers is the key component of any
Eclipse Project. Ideally, this community should be an open,
transparent, inclusive, and diverse community of Committers and
(non-Committer) Contributors. Attracting new Contributors and
Committers to an open source project is time consuming and requires
active recruiting, not just passive "openness". The Project Leadership
must make reasonable efforts to encourage and nurture promising new
Contributors. </i>
<ul>
<li><i> Projects must have the diversity goals to ensure
diversity of thought and avoiding relying on any one company or
organization. At the same time, we acknowledge that enforcing a
particular diversity metric is a poor way to achieve these goals;
rather we expect the project leadership to help the diversity evolve
organically.
</i></li>
<li><i> Diversity is a means to an end, not an end in itself,
thus diversity goals will differ by project based on the other
accomplishments of the project(s).
</i></li>
<li><i> Project are required to explain their diversity efforts
and accomplishments during Reviews.<br>
</i></li>
</ul>
</li>
</ul>
<h2><i>6.3 Reviews</i></h2>
<i><...></i><br>
<i>The criteria for the successful completion of each type of Review
will be documented in writing by the EMO in guidelines made available
via the <a class="moz-txt-link-abbreviated" href="http://www.eclipse.org">www.eclipse.org</a> website. Such guidelines will include, but are
not limited to the following:</i>
<ol>
<li><i> Clear evidence that the project has vibrant committer,
adopter and user communities as appropriate for the type of Review.
</i></li>
<li><i> Reasonable diversity in its committer population as
appropriate for the type of Review. Diversity status must be provided
not only as number of people/companies, but also in terms of effort
provided by those people/companies. </i></li>
</ol>
<h3><i>6.3.2 Graduation Review</i></h3>
<i><...></i><br>
</blockquote>
<ul>
<ul>
<li><i> active and sufficiently diverse communities: adopters,
developers, and users</i>
</li>
</ul>
</ul>
Bjorn interprets theses as requiring diversity and argues that these
requirements are not enforced. And then he argues that unenforced
requirements weaken all requirements and hence we should eliminate
unenforced requirements. There is certainly wisdom in this attitude
of eliminating rules that aren't followed nor enforced. Originally I
had thought he was just flame baiting us, but Bjorn wouldn't do that!
:-p<br>
<br>
The thing is, I don't read those rules as strictly requiring diversity
but rather as recognizing that diversity is extremely important and
something we should always keep in the forefront of our thinking. When
diversity is lacking, it should be explained and efforts to improve it
should be taken, but I think that's exactly what the verbiage above is
saying. The recent fiasco with VE where folks trying to provide a
Europa compatible version find themselves unable to make progress
because there is effectively no active committer community willing or
able to commit the changes is an excellent example of the worst that
can happen. So I'm dead set against removing any of the diversity
language from the development process. <br>
<br>
Looking at the issue as it relates more directly to my own project(s)
with EMFT as an example, that project has a number of components that
have a very small set of committers, often just one. So while the
project has a whole is certainly diverse by any standard of diversity,
individual components are typically not, and even that could ultimately
lead to problems. But I'm not the diversity fairy with a pretty wand
that I can use to magically bestow diversity on others. (Doesn't that
conjure up an ugly picture!) It's important to note too that the
community is far more likely to take on the role of a harsh critic than
the role of a contributor, with like a 10 to 1 ratio. And the truly
saddest thing of all is the chicken and the egg problem of having such
a small committer base that properly handling contributions is
inhibited. An excellent example of this is <a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=75625">https://bugs.eclipse.org/bugs/show_bug.cgi?id=75625</a>
which in my opinion is the single most useful thing we could do for EMF
in the next release, but which other priorities are preventing us from
handling with the kind of speed that I think it deserves; it may be a
couple of months at least before us committers can set aside time to
focus on this. :-(<br>
<br>
We'll be sure to bring up the diversity issue, and VE in particular, as
part of our committer issues segment of the coming board meeting.<br>
<br>
<br>
Scott Lewis wrote:
<blockquote cite="mid:fc76g8$h9l$1@build.eclipse.org" type="cite">I
understand there there is a f2f Board meeting coming up on Sept 19, and
I was wondering about the committer reps thinking WRT the recent
blogging WRT project diversity:
<br>
<br>
e.g. Bjorn's blog entry:
<br>
<br>
<a class="moz-txt-link-freetext" href=" http://eclipse-projects.blogspot.com/2007/09/diversity-just- lip-service.html"> http://eclipse-projects.blogspot.com/2007/09/diversity-just- lip-service.html</a>
<br>
<br>
Thanksinadvance for your efforts.
<br>
</blockquote>
<br>
</body>
</html>
--------------040408020006050406040307--
|
|
|
| Re: Project diversity [message #8870 is a reply to message #8849] |
Wed, 12 September 2007 15:05 |
| Eclipse User |
|
|
|
Originally posted by: slewis.composent.com
Hi Ed,
Ed Merks wrote:
> Scott,
>
> I did comment on it in the blog. Here are the references from the
> development process to which Bjorn is referring.
>
<stuff deleted>
> The thing is, I don't read those rules as strictly requiring diversity
> but rather as recognizing that diversity is extremely important and
> something we should always keep in the forefront of our thinking.
I would say that the difference between your 'recognition' and a
'requirement' is the extent to which to it's actually imposed when it's
not 'comfortable'...for the good of the community.
When
> diversity is lacking, it should be explained and efforts to improve it
> should be taken, but I think that's exactly what the verbiage above is
> saying.
But the verbiage does nothing. And current enforcement by
Foundation/members is not present (as per Bjorn's point).
The recent fiasco with VE where folks trying to provide a Europa
> compatible version find themselves unable to make progress because there
> is effectively no active committer community willing or able to commit
> the changes is an excellent example of the worst that can happen. So
> I'm dead set against removing any of the diversity language from the
> development process.
I agree.
>
> Looking at the issue as it relates more directly to my own project(s)
> with EMFT as an example, that project has a number of components that
> have a very small set of committers, often just one. So while the
> project has a whole is certainly diverse by any standard of diversity,
> individual components are typically not, and even that could ultimately
> lead to problems. But I'm not the diversity fairy with a pretty wand
> that I can use to magically bestow diversity on others. (Doesn't that
> conjure up an ugly picture!) It's important to note too that the
> community is far more likely to take on the role of a harsh critic than
> the role of a contributor, with like a 10 to 1 ratio. And the truly
> saddest thing of all is the chicken and the egg problem of having such a
> small committer base that properly handling contributions is inhibited.
> An excellent example of this is
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=75625 which in my opinion
> is the single most useful thing we could do for EMF in the next release,
> but which other priorities are preventing us from handling with the kind
> of speed that I think it deserves; it may be a couple of months at least
> before us committers can set aside time to focus on this. :-(
>
> We'll be sure to bring up the diversity issue, and VE in particular, as
> part of our committer issues segment of the coming board meeting.
Thanks.
Scott
|
|
| |
| Re: Project diversity [message #560704 is a reply to message #8835] |
Wed, 12 September 2007 12:41 |
 Ed Merks
Messages: 33139
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------040408020006050406040307
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Scott,
I did comment on it in the blog. Here are the references from the
development process to which Bjorn is referring.
/2.5 Three Communities/
/Essential to the Purposes of the Eclipse Foundation is the
development of three inter-related communities around each Project: /
* /*Contributors* and *Committers* - a thriving, diverse and
active community of developers is the key component of any
Eclipse Project. Ideally, this community should be an open,
transparent, inclusive, and diverse community of Committers
and (non-Committer) Contributors. Attracting new Contributors
and Committers to an open source project is time consuming and
requires active recruiting, not just passive "openness". The
Project Leadership must make reasonable efforts to encourage
and nurture promising new Contributors. /
o / Projects must have the diversity goals to ensure
diversity of thought and avoiding relying on any one
company or organization. At the same time, we
acknowledge that enforcing a particular diversity metric
is a poor way to achieve these goals; rather we expect
the project leadership to help the diversity evolve
organically. /
o / Diversity is a means to an end, not an end in itself,
thus diversity goals will differ by project based on the
other accomplishments of the project(s). /
o / Project are required to explain their diversity
efforts and accomplishments during Reviews.
/
/6.3 Reviews/
/<...>/
/The criteria for the successful completion of each type of Review
will be documented in writing by the EMO in guidelines made
available via the www.eclipse.org website. Such guidelines will
include, but are not limited to the following:/
1. / Clear evidence that the project has vibrant committer,
adopter and user communities as appropriate for the type of
Review. /
2. / Reasonable diversity in its committer population as
appropriate for the type of Review. Diversity status must be
provided not only as number of people/companies, but also in
terms of effort provided by those people/companies. /
/6.3.2 Graduation Review/
/<...>/
o / active and sufficiently diverse communities: adopters,
developers, and users/
Bjorn interprets theses as requiring diversity and argues that these
requirements are not enforced. And then he argues that unenforced
requirements weaken all requirements and hence we should eliminate
unenforced requirements. There is certainly wisdom in this attitude of
eliminating rules that aren't followed nor enforced. Originally I had
thought he was just flame baiting us, but Bjorn wouldn't do that! :-p
The thing is, I don't read those rules as strictly requiring diversity
but rather as recognizing that diversity is extremely important and
something we should always keep in the forefront of our thinking. When
diversity is lacking, it should be explained and efforts to improve it
should be taken, but I think that's exactly what the verbiage above is
saying. The recent fiasco with VE where folks trying to provide a Europa
compatible version find themselves unable to make progress because there
is effectively no active committer community willing or able to commit
the changes is an excellent example of the worst that can happen. So
I'm dead set against removing any of the diversity language from the
development process.
Looking at the issue as it relates more directly to my own project(s)
with EMFT as an example, that project has a number of components that
have a very small set of committers, often just one. So while the
project has a whole is certainly diverse by any standard of diversity,
individual components are typically not, and even that could ultimately
lead to problems. But I'm not the diversity fairy with a pretty wand
that I can use to magically bestow diversity on others. (Doesn't that
conjure up an ugly picture!) It's important to note too that the
community is far more likely to take on the role of a harsh critic than
the role of a contributor, with like a 10 to 1 ratio. And the truly
saddest thing of all is the chicken and the egg problem of having such a
small committer base that properly handling contributions is inhibited.
An excellent example of this is
https://bugs.eclipse.org/bugs/show_bug.cgi?id=75625 which in my opinion
is the single most useful thing we could do for EMF in the next release,
but which other priorities are preventing us from handling with the kind
of speed that I think it deserves; it may be a couple of months at least
before us committers can set aside time to focus on this. :-(
We'll be sure to bring up the diversity issue, and VE in particular, as
part of our committer issues segment of the coming board meeting.
Scott Lewis wrote:
> I understand there there is a f2f Board meeting coming up on Sept 19,
> and I was wondering about the committer reps thinking WRT the recent
> blogging WRT project diversity:
>
> e.g. Bjorn's blog entry:
>
> http://eclipse-projects.blogspot.com/2007/09/diversity-just- lip-service.html
>
>
> Thanksinadvance for your efforts.
--------------040408020006050406040307
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Scott,<br>
<br>
I did comment on it in the blog. Here are the references from the
development process to which Bjorn is referring.<br>
<blockquote>
<h2><i>2.5 Three Communities</i></h2>
<i>Essential to the Purposes of the Eclipse Foundation is the
development of three inter-related communities around each Project:
</i>
<ul>
<li> <i><b>Contributors</b> and <b>Committers</b> - a thriving,
diverse and active community of developers is the key component of any
Eclipse Project. Ideally, this community should be an open,
transparent, inclusive, and diverse community of Committers and
(non-Committer) Contributors. Attracting new Contributors and
Committers to an open source project is time consuming and requires
active recruiting, not just passive "openness". The Project Leadership
must make reasonable efforts to encourage and nurture promising new
Contributors. </i>
<ul>
<li><i> Projects must have the diversity goals to ensure
diversity of thought and avoiding relying on any one company or
organization. At the same time, we acknowledge that enforcing a
particular diversity metric is a poor way to achieve these goals;
rather we expect the project leadership to help the diversity evolve
organically.
</i></li>
<li><i> Diversity is a means to an end, not an end in itself,
thus diversity goals will differ by project based on the other
accomplishments of the project(s).
</i></li>
<li><i> Project are required to explain their diversity efforts
and accomplishments during Reviews.<br>
</i></li>
</ul>
</li>
</ul>
<h2><i>6.3 Reviews</i></h2>
<i><...></i><br>
<i>The criteria for the successful completion of each type of Review
will be documented in writing by the EMO in guidelines made available
via the <a class="moz-txt-link-abbreviated" href="http://www.eclipse.org">www.eclipse.org</a> website. Such guidelines will include, but are
not limited to the following:</i>
<ol>
<li><i> Clear evidence that the project has vibrant committer,
adopter and user communities as appropriate for the type of Review.
</i></li>
<li><i> Reasonable diversity in its committer population as
appropriate for the type of Review. Diversity status must be provided
not only as number of people/companies, but also in terms of effort
provided by those people/companies. </i></li>
</ol>
<h3><i>6.3.2 Graduation Review</i></h3>
<i><...></i><br>
</blockquote>
<ul>
<ul>
<li><i> active and sufficiently diverse communities: adopters,
developers, and users</i>
</li>
</ul>
</ul>
Bjorn interprets theses as requiring diversity and argues that these
requirements are not enforced. And then he argues that unenforced
requirements weaken all requirements and hence we should eliminate
unenforced requirements. There is certainly wisdom in this attitude
of eliminating rules that aren't followed nor enforced. Originally I
had thought he was just flame baiting us, but Bjorn wouldn't do that!
:-p<br>
<br>
The thing is, I don't read those rules as strictly requiring diversity
but rather as recognizing that diversity is extremely important and
something we should always keep in the forefront of our thinking. When
diversity is lacking, it should be explained and efforts to improve it
should be taken, but I think that's exactly what the verbiage above is
saying. The recent fiasco with VE where folks trying to provide a
Europa compatible version find themselves unable to make progress
because there is effectively no active committer community willing or
able to commit the changes is an excellent example of the worst that
can happen. So I'm dead set against removing any of the diversity
language from the development process. <br>
<br>
Looking at the issue as it relates more directly to my own project(s)
with EMFT as an example, that project has a number of components that
have a very small set of committers, often just one. So while the
project has a whole is certainly diverse by any standard of diversity,
individual components are typically not, and even that could ultimately
lead to problems. But I'm not the diversity fairy with a pretty wand
that I can use to magically bestow diversity on others. (Doesn't that
conjure up an ugly picture!) It's important to note too that the
community is far more likely to take on the role of a harsh critic than
the role of a contributor, with like a 10 to 1 ratio. And the truly
saddest thing of all is the chicken and the egg problem of having such
a small committer base that properly handling contributions is
inhibited. An excellent example of this is <a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=75625">https://bugs.eclipse.org/bugs/show_bug.cgi?id=75625</a>
which in my opinion is the single most useful thing we could do for EMF
in the next release, but which other priorities are preventing us from
handling with the kind of speed that I think it deserves; it may be a
couple of months at least before us committers can set aside time to
focus on this. :-(<br>
<br>
We'll be sure to bring up the diversity issue, and VE in particular, as
part of our committer issues segment of the coming board meeting.<br>
<br>
<br>
Scott Lewis wrote:
<blockquote cite="mid:fc76g8$h9l$1@build.eclipse.org" type="cite">I
understand there there is a f2f Board meeting coming up on Sept 19, and
I was wondering about the committer reps thinking WRT the recent
blogging WRT project diversity:
<br>
<br>
e.g. Bjorn's blog entry:
<br>
<br>
<a class="moz-txt-link-freetext" href=" http://eclipse-projects.blogspot.com/2007/09/diversity-just- lip-service.html"> http://eclipse-projects.blogspot.com/2007/09/diversity-just- lip-service.html</a>
<br>
<br>
Thanksinadvance for your efforts.
<br>
</blockquote>
<br>
</body>
</html>
--------------040408020006050406040307--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Project diversity [message #560708 is a reply to message #8849] |
Wed, 12 September 2007 15:05 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
Ed Merks wrote:
> Scott,
>
> I did comment on it in the blog. Here are the references from the
> development process to which Bjorn is referring.
>
<stuff deleted>
> The thing is, I don't read those rules as strictly requiring diversity
> but rather as recognizing that diversity is extremely important and
> something we should always keep in the forefront of our thinking.
I would say that the difference between your 'recognition' and a
'requirement' is the extent to which to it's actually imposed when it's
not 'comfortable'...for the good of the community.
When
> diversity is lacking, it should be explained and efforts to improve it
> should be taken, but I think that's exactly what the verbiage above is
> saying.
But the verbiage does nothing. And current enforcement by
Foundation/members is not present (as per Bjorn's point).
The recent fiasco with VE where folks trying to provide a Europa
> compatible version find themselves unable to make progress because there
> is effectively no active committer community willing or able to commit
> the changes is an excellent example of the worst that can happen. So
> I'm dead set against removing any of the diversity language from the
> development process.
I agree.
>
> Looking at the issue as it relates more directly to my own project(s)
> with EMFT as an example, that project has a number of components that
> have a very small set of committers, often just one. So while the
> project has a whole is certainly diverse by any standard of diversity,
> individual components are typically not, and even that could ultimately
> lead to problems. But I'm not the diversity fairy with a pretty wand
> that I can use to magically bestow diversity on others. (Doesn't that
> conjure up an ugly picture!) It's important to note too that the
> community is far more likely to take on the role of a harsh critic than
> the role of a contributor, with like a 10 to 1 ratio. And the truly
> saddest thing of all is the chicken and the egg problem of having such a
> small committer base that properly handling contributions is inhibited.
> An excellent example of this is
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=75625 which in my opinion
> is the single most useful thing we could do for EMF in the next release,
> but which other priorities are preventing us from handling with the kind
> of speed that I think it deserves; it may be a couple of months at least
> before us committers can set aside time to focus on this. :-(
>
> We'll be sure to bring up the diversity issue, and VE in particular, as
> part of our committer issues segment of the coming board meeting.
Thanks.
Scott
|
|
| |
Goto Forum:
Current Time: Tue Apr 23 07:01:51 GMT 2024
Powered by FUDForum. Page generated in 0.03797 seconds |
] 
Search
Help
Register
Login
Home
