[pydata-outreach-staff] Good first bugs

[Asheesh Laroia]

Hey all,

(This is mostly for y'all's curiosity; feel free to not read it 
pre-sprint. I'll take care of any action items in here.)

I've bookmarked a few bugs here: 
http://bookmarks.makesad.us/insipid.cgi?tag=pandas

You can see on that page:

* Some bugs are 'bitesize', which means they should be fairly easy for 
someone with substantial Python background to identify the problem and 
submit a fix.

* Some bugs are 'mouthful's, which means they should be fairly easy for 
someone with substantial Python background to identify the problem, but 
the fix might require more care.

I've commented on quite a few bugs tonight with information on how to 
solve them, which I hope will smooth the on-ramp for people as they take 
care of their first issues. I suspect that once everyone has worked on any 
bug, or seen someone else work on it, they will get the same quick sense 
that I have for if a bug is bitesize.

I would prefer to move the tagging to Github, rather than my personal 
bookmarks site; I'll talk to Chang about giving me access so I can do 
that.

I did see the [Community] Github label; my list has bugs I've hand-picked, 
and my list contains only issues where the next step is very clear. The 
"Community" list seems a little more free-form. Chang, maybe we can chat in 
person for a moment about how to best merge these efforts.

Another issue I'll bring up with Chang before the sprint is the question 
of avoiding duplicate work. At a recent workshop I helped run, many 
attendees picked the same easy tasks to work on, resulting in duplication. 
I think the best strategy for that is to tell everyone to log into Github 
and assign bugs to themselves as soon as they start working on them. 
Github's website will automatically sync that to other people's browsers 
in real-time, I believe.

I've seen this handled a few ways:

* People can join an IRC channel and talk about which issue they are 
working on. (Downside: people lose connectivity to IRC, or easily forget 
to actually say they're working on it, or the least-experienced people 
forget to check IRC before starting something so they end up working on 
duplicate issues.)

* People can mark what they're working on on a wiki page. (Similar 
problem.)

* People mark the issues as assigned to them in the project bug tracker. 
(Downside: Some large fraction of these issues might have to be 
"de-assigned" from an event attendee, a few days later, who never got 
around to fixing these. I can personally be the one to do that if we need 
a volunteer.)

I prefer the last way, but I'm willing to work with whatever we 
(especially Chang) is comfortable with.

I've chosen mostly tickets not in the 0.10 milestone. I haven't looked 
into the pandas release process, so I hope that adding 0.11 tickets to the 
queue for new contributors won't slow down the 0.10 release in a way the 
project doesn't like.

Thanks, and see you all soon,

-- Asheesh.