[IPython-dev] Should I still contribute to IPython ?

Mon Dec 17 19:18:53 EST 2012

On Mon, Dec 17, 2012 at 5:02 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> On Mon, Dec 17, 2012 at 2:36 PM, Aaron Meurer <asmeurer at gmail.com> wrote:
>> I remember reading about a study that said that open source projects
>> that have funded developers actually get less contributions (or at
>> least fewer contributors) because there is a mindset of, "why should I
>> contribute when there is someone who is paid to do it? Surely that
>> person/persons will get around to fixing the issue themselves."  I
>> think the email Matthias received is indicative of this mindset.
>> Clearly it is wrong (obviously, more contributions are still more
>> contributions), but I think you should really think about how to make
>> this permeate through your community, so that you minimize the number
>> of people who end up thinking this way.
>>
>> One good thing to do, as Matthias said, is to always encourage people
>> to write their own patches.  It is an investment to spend a day
>> helping someone write up a pull request for a fix when you could have
>> done the whole thing yourself in under half an hour, but by guiding
>> the new contributor, you potentially gain a new developer.  Ondřej
>> Čertík wrote a blog post a while back about how he managed to make
>> SymPy such a successful community
>> http://ondrejcertik.blogspot.com/2009/05/my-experience-with-running-opensource.html.
>>  The gist of it is what I just said.
>>
>> For your situation, I think this additionally sends the message that
>> it is not only OK, but encouraged to send your own patches, rather
>> than wait for those people who are being paid to fix the bug for you.
>
> Yes, I really like how Ondrej has always encouraged people to send
> patches and I think we need to encourage people to do that.  Part of
> the reality is that a good portion of our Sloan funded time on the
> project will be reviewing pull requests - and that is a good thing.

It's really amazing actually.  90% of time, all you have to do is say
"can you send a pull request fixing that?" (especially if it's clear
that the person knows how to fix the issue), and they will do it. Even
if you would have guessed that the person would not be able to do it,
because they seem just like a user, and not someone who knows how to
find bugs in the code base or use git, they surprise you more often
than not.  I think just the simple act of asking someone to contribute
makes them feel responsible for doing it, which they did not feel
before.

>
>>> * How do we coordinate all of this activity?  Already, our github
>>> issues are becoming unusable because of the sheer number of them.  We
>>> have to figure out a better way of using github issues, wiki pages,
>>> etc. to coordinate the increased activity the grant will bring.
>>
>> I'm curious how you end up solving this problem.  I've found the
>> GitHub issues to be minimalistic, which makes them easy to use, but
>> they also lack in some key features that make managing thousands of
>> issues bearable.
>
> I know it probably sounds heretical, but I think that part of the
> solution has to be to reduce the number of issues.  I don't mean by
> closing issues by working harder and coding more, I mean simply
> *closing* them outright to reflect the reality that we are not going
> to work on them anytime soon.  There is no universe where it is useful
> to have thousands of issues.  How many can each developer
> realistically keep track of?  A few dozen?  When there are more than
> that we simply ignore the issues and work on the things we want to
> work on...I was recently talking to the lead developer of a large open
> source project that has this problem, and he said "oh it's horrible
> and I completely ignore our issues on github"  Personally, when I am
> working heavily on the notebook, I maintain my own "issues list" in a
> markdown document on my desktop.  We have to figure out a better
> way...

This does sound heretical to me, but I have a personality that
dislikes deleting anything.  I personally think of issues as ways of
organizing discussions about problems/enhancement requests so that
when the issue comes up again, it is easy to see what was already
discussed.

SymPy has over 1000 open issues in our issue tracker (of over 3000
total).  Admittedly, quite a few of the older of these are outdated
and should be closed, but we don't take the time to go through them.
But I personally feel that that many issues is manageable because we
have extensive labeling, and Google Code has great search
functionality (which GitHub lacks), so that I feel that I can almost
always find the issue I want if I look for it.

I'm actually reminded of the one time that I posted a message to the
git mailing list.  I asked them if they had an issue tracker, and they
told me that they don't, but rather they *just* use the mailing list.
To quote Junio Hamano, the lead developer of git:

"What we do is to take advantage of the fact that issues people do care
about are important ones, and others that nobody cares about are not worth
pursuing.

"In a sense, 'people forgetting' is a lot more important than 'people
remembering' to filter unimportant issues (issues that are so unimportant
that even the original complainer does not bother to come back and
re-raise it)."

(By the way, this isn't the only strange thing about the git
community. Their mailing list requires no registration of any kind to
post, meaning that about half the messages on the list are spam).

Aaron Meurer

>
> Cheers,
>
> Brian
>
>>> * Currently, we don't really have any long/medium term planning for
>>> the project.  Our current model works great for attracting the types
>>> of contributions we are getting right now, but it makes it very
>>> difficult to tackle larger projects that require a coordinated and
>>> sustained effort by multiple people.  I don't know what it will look
>>> like, but we are going to need to do this type of planning for the
>>> project.
>>> * How do we manage communication?  Verbal communication is much more
>>> efficient than emails or even IRC.  The 4 people at Berkeley will have
>>> an incredible advantage in being able to talk daily.  We don't want to
>>> cripple or remove that advantage, but we need to figure out how to
>>> include other core devs and people from the community.  This is
>>> particularly relevant to myself as I am the only person involved in
>>> the Sloan work that is not at Berkeley.
>>
>> An idea floated around SymPy at some point to use Google+ hangouts
>> (basically, multi-way video chats).  We haven't tried it yet, but it
>> seems like it might work well.
>>
>> Aaron Meurer
>>
>>>
>>> Cheers,
>>>
>>> Brian
>>>
>>>
>>>> Sorry for the length,
>>>> --
>>>> Matthias
>>>>
>>>>
>>>>
>>>> [Grant announce on HN] http://news.ycombinator.com/item?id=4909070
>>>> And a small link, also from hacker news to conclude :
>>>> [Dear Open Source Project Leader: Quit Being A Jerk]
>>>> http://news.ycombinator.com/item?id=4921152
>>>>
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Brian E. Granger
>>> Cal Poly State University, San Luis Obispo
>>> bgranger at calpoly.edu and ellisonbg at gmail.com
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev