[IPython-dev] Should I still contribute to IPython ?
Mon Dec 17 18:52:55 CST 2012
As someone who just started to contribute before the news of the Sloan funding came out,
I'm (1) happy to see this thread, because I was (privately) having some of the same questions
and (2) happy to hear that you guys are still committed to encouraging community involvement.
Also glad to hear that there will be more time for reviewing PRs!
I understand the desire/need to have a more full featured issue tracking solution, but I think for
attracting and retaining new contributors, the minimal interface of github issues is really an asset.
(Obviously this needs to be balanced against the needs of the core team who have to filter through
But from personal experience, I probably would not be contributing if my first impression of the
processes had been that contributing was some elaborate and "highly managed" process. At that
very first stage of involvement, friction matters.
On Dec 17, 2012, at 4:18 PM, Aaron Meurer wrote:
> On Mon, Dec 17, 2012 at 5:02 PM, Brian Granger <email@example.com> wrote:
>> On Mon, Dec 17, 2012 at 2:36 PM, Aaron Meurer <firstname.lastname@example.org> 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
>>> 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
>>>> * 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
> 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
> 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
> "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
>>>> * 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
>>>> * 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
>>>>> Sorry for the length,
>>>>> [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]
>>>>> IPython-dev mailing list
>>>> Brian E. Granger
>>>> Cal Poly State University, San Luis Obispo
>>>> email@example.com and firstname.lastname@example.org
>>>> IPython-dev mailing list
>>> IPython-dev mailing list
>> Brian E. Granger
>> Cal Poly State University, San Luis Obispo
>> email@example.com and firstname.lastname@example.org
>> IPython-dev mailing list
> IPython-dev mailing list
More information about the IPython-dev