[IPython-dev] No displayhook triggered for raw 'asdf'

[Brian Granger]

Fernando,

> Yes, same here :)  I feel terrible that we've gotten a lot of good
> contributions recently, and we're falling behind on reviews/feedback.
> I'm trying to get plugged back into everything and doing some of that
> as well, because I've been *terrible* lately.  This recent excellent
> post on building open source communities:

Yes, that is the hidden side of code review and lots of (great!)
contributions.  It takes a ton of time just to review.  Between the
different projects I am involved in, I spend a significant amount of
time doing review (more than I code these days).

> http://www.codesimplicity.com/post/open-source-community-simplified/
>
> really made me think hard about this and how I try to organize my
> priorities so that, when faced with very limited time (as I inevitably
> am) I can still be effective with the project.  This section in
> particular:
>
> """
> Respond to contributions immediately.
>
> The Bugzilla Project has a system of code reviews that requires that
> all new contributions be reviewed by an experienced developer before
> they can become part of Bugzilla. There have been various complaints
> about the system over the years, but analyzing the survey data showed
> that people leave the project because getting a review takes too long,
> not because the reviews are too hard. In fact, the reviews can be as
> hard as you want as long as they happen almost instantly after
> somebody submits a contribution.

I *completely* believe this.

> People don’t (usually) mind having to revise a contribution. They even
> generally don’t mind revising it several times. But they do mind if
> they post a patch, don’t get a review for three months, and then they
> have to revise it, only to wait another three months to be told that
> they have to revise it again. It’s the delay that matters, not the
> level of quality control.
> """

Yep.

> spells out very well the importance of good feedback to new contributors.
>
> I feel super guilty about having dropped the ball on the wave that
> came from Scipy India; I hope those contributors will still keep an
> interest in the project.
>
> Anyway, the good thing about screwing up badly is that your next step
> is likely to be an improvement ;)

:)

One thing I think we should do is figure out a way of dividing the
review workload so nothing slips through the cracks.  When a review
comes in, do we want to assign a "lead" reviewer that will make sure
it gets pushed through in a timely manner?  Sort of like journals
assign reviewers to articles.  Our current situation is like running a
peer review journal, without an editor to manage the review proces...

Cheers,

Brian

> Cheers,
>
> f
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com