Diversity

[Ian Holsman <kr...@gmail.com>]

one of the gates on the incubator is diversity.

quoting Noel from a message in general@:
> Can you confirm the community diversity?  That is one thing I could not tell
> straight off, although I do note the comment in July 2005 about crossing the
> threshold, and observe that there have been at least 4 committers  added
> since then.  So I'm assuming that it is fine, and therefore +1.

As a mentor on Solr, I thought I would bring this up. We need a bit
more diversity in who is checking in code to SVN.

An approach to this would be for the CNET developers to back off on
the commits (even though they are faster/more experienced at them) and
let others step up.

I would hate to have this project knocked back because of lack of
diversisty of contributors.

regards
Ian

--
Ian@Holsman.net -- blog: http://feh.holsman.net/ -- PH: ++61-3-9877-0909

If everything seems under control, you're not going fast enough. -
Mario Andretti

Re: Diversity

[Yoav Shapira <yo...@apache.org>]

Hola,
My take on this is fairly simple:

- Have a publicly-visible and up-to-date todo list (be it a wiki page
or whatever)
- Encourage contributions from new people whenever and however
possible.  If someone seems clueful, encourage them to submit easy
patches and commit the patches for them.  Get them involved however
possible.
- Be open, be inviting, be welcoming...

You shouldn't explicitly NOT do something in order to give someone
else a chance to do it -- there will always be enough work.

If the above are consistently done, the chances of a dynamic community
are good, and even if there are no new committers over the next few
months, you've established the you understand the Apache Way and have
an open community.

Yoav

On 3/13/06, Ian Holsman <Ia...@holsman.net> wrote:
> On 3/14/06, Chris Hostetter <ho...@fucit.org> wrote:
> >
> > : > An approach to this would be for the CNET developers to back off on
> > : > the commits (even though they are faster/more experienced at them) and
> > : > let others step up.
> >
> > in general that seems really counter intuative to me, but i think Doug's
> > right on the money...
>
> the reasoning behind that was to let others have a chance of fixing
> things.. for example when a bug is mentioned on the list, you guys are
> all over it.
> anyways.. doug's way is probably a better approach.. my main reason
> for posting was to get people thinking about this gate, and ways to
> build up the community. The part i was trying to get to was to make it
> easier for people to contribute... which you guys stated more clearly.
>
> >
> > : I'd hate to see this.  I think the key is to get more folks using it.
> > : Contributions come from use.  So the focus should be on attracting
> > : users, rather than adding features.  Missing features are opportunities
> > : for new developers.  You'll get users with a great out-of-box
> > : experience, that does most (but perhaps not quite all) of what they want.
> >
> > So it seems like CNET folks should focus on making the existing
> > functionality easier to use, and make it easier for developers who are
> > less familar with the code base to add new featrues -- rather then adding
> > new features ourselves.
>
> I don't know.. It's hard.. by adding more features you'll attract more
> people as the product will be of greater use to them, but by adding
> more features you'll also be raising the bar on the level of knowledge
> required to contribute back to it (if you are not careful)
>
> So your point on making the code easier to use is spot-on.
> maybe even documenting what kind of new features you think would be
> great additions to Solr might help..
>
> Maybe a wiki page saying all the ideas you guys have thought of but
> haven't had time to implement. basically we're after getting a spark
> created in a new-to-solr developer's head.
>
> >
> > So things like the improving javadocs and unit testing of the existing
> > code base are "good commits" for yonik and i to work on, because they will
> > (hopefully) encourage other new developers to contribute.  but adding new
> > functinality (like a plugin supporting for faceted searching, or
> > autoloading of data from a DB) are best left for future (non-CNET)
> > commiters.
> >
> > is that what you had in mind Ian?
>
> ok.. let me be clear here.. CNET comitters are still very important to
> the upkeep of the project, and new functionality from them would
> always be great.. I'm not anti-cnet ppl (some of best friends are CNET
> developers ;-) just that they need to leave some low hanging fruit so
> that others can grab it.
>
>
>
> >
> >
> >
> > -Hoss
> >
> >
>
>
> --
> Ian@Holsman.net -- blog: http://feh.holsman.net/ -- PH: ++61-3-9877-0909
>
> If everything seems under control, you're not going fast enough. -
> Mario Andretti
>


--
Yoav Shapira
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
yoavs@computer.org / www.yoavshapira.com

Re: Diversity

[Chris Hostetter <ho...@fucit.org>]

: Maybe a wiki page saying all the ideas you guys have thought of but
: haven't had time to implement. basically we're after getting a spark
: created in a new-to-solr developer's head.

We'll, we've got the TaskList on the Solr wiki...

	http://wiki.apache.org/solr/TaskList

...I guess we should promote that a little more.

: ok.. let me be clear here.. CNET comitters are still very important to
: the upkeep of the project, and new functionality from them would
: always be great.. I'm not anti-cnet ppl (some of best friends are CNET
: developers ;-) just that they need to leave some low hanging fruit so
: that others can grab it.

Right.  understood.



-Hoss

Re: Diversity

[Ian Holsman <Ia...@Holsman.net>]

On 3/14/06, Chris Hostetter <ho...@fucit.org> wrote:
>
> : > An approach to this would be for the CNET developers to back off on
> : > the commits (even though they are faster/more experienced at them) and
> : > let others step up.
>
> in general that seems really counter intuative to me, but i think Doug's
> right on the money...

the reasoning behind that was to let others have a chance of fixing
things.. for example when a bug is mentioned on the list, you guys are
all over it.
anyways.. doug's way is probably a better approach.. my main reason
for posting was to get people thinking about this gate, and ways to
build up the community. The part i was trying to get to was to make it
easier for people to contribute... which you guys stated more clearly.

>
> : I'd hate to see this.  I think the key is to get more folks using it.
> : Contributions come from use.  So the focus should be on attracting
> : users, rather than adding features.  Missing features are opportunities
> : for new developers.  You'll get users with a great out-of-box
> : experience, that does most (but perhaps not quite all) of what they want.
>
> So it seems like CNET folks should focus on making the existing
> functionality easier to use, and make it easier for developers who are
> less familar with the code base to add new featrues -- rather then adding
> new features ourselves.

I don't know.. It's hard.. by adding more features you'll attract more
people as the product will be of greater use to them, but by adding
more features you'll also be raising the bar on the level of knowledge
required to contribute back to it (if you are not careful)

So your point on making the code easier to use is spot-on.
maybe even documenting what kind of new features you think would be
great additions to Solr might help..

Maybe a wiki page saying all the ideas you guys have thought of but
haven't had time to implement. basically we're after getting a spark
created in a new-to-solr developer's head.

>
> So things like the improving javadocs and unit testing of the existing
> code base are "good commits" for yonik and i to work on, because they will
> (hopefully) encourage other new developers to contribute.  but adding new
> functinality (like a plugin supporting for faceted searching, or
> autoloading of data from a DB) are best left for future (non-CNET)
> commiters.
>
> is that what you had in mind Ian?

ok.. let me be clear here.. CNET comitters are still very important to
the upkeep of the project, and new functionality from them would
always be great.. I'm not anti-cnet ppl (some of best friends are CNET
developers ;-) just that they need to leave some low hanging fruit so
that others can grab it.



>
>
>
> -Hoss
>
>


--
Ian@Holsman.net -- blog: http://feh.holsman.net/ -- PH: ++61-3-9877-0909

If everything seems under control, you're not going fast enough. -
Mario Andretti

Re: Diversity

[Chris Hostetter <ho...@fucit.org>]

: > An approach to this would be for the CNET developers to back off on
: > the commits (even though they are faster/more experienced at them) and
: > let others step up.

in general that seems really counter intuative to me, but i think Doug's
right on the money...

: I'd hate to see this.  I think the key is to get more folks using it.
: Contributions come from use.  So the focus should be on attracting
: users, rather than adding features.  Missing features are opportunities
: for new developers.  You'll get users with a great out-of-box
: experience, that does most (but perhaps not quite all) of what they want.

So it seems like CNET folks should focus on making the existing
functionality easier to use, and make it easier for developers who are
less familar with the code base to add new featrues -- rather then adding
new features ourselves.

So things like the improving javadocs and unit testing of the existing
code base are "good commits" for yonik and i to work on, because they will
(hopefully) encourage other new developers to contribute.  but adding new
functinality (like a plugin supporting for faceted searching, or
autoloading of data from a DB) are best left for future (non-CNET)
commiters.

is that what you had in mind Ian?



-Hoss

Re: Diversity

[Doug Cutting <cu...@apache.org>]

Ian Holsman wrote:
> As a mentor on Solr, I thought I would bring this up. We need a bit
> more diversity in who is checking in code to SVN.

Yes, that's definitely true.

> An approach to this would be for the CNET developers to back off on
> the commits (even though they are faster/more experienced at them) and
> let others step up.

I'd hate to see this.  I think the key is to get more folks using it. 
Contributions come from use.  So the focus should be on attracting 
users, rather than adding features.  Missing features are opportunities 
for new developers.  You'll get users with a great out-of-box 
experience, that does most (but perhaps not quite all) of what they want.

Doug