[Devel] Our three next releases

[Asheesh Laroia]

It's been really, really exciting having more contributors and 
possible contributors join the #openhatch IRC channel and this 
email list. We've gotten lots of new people in the past six months, 
and together we've done some really great things.

In this email, I want to share some ideas about focusing the 
OpenHatch development community on releases targeted at particular 
sets of issues. I want to hear from you all if you like the idea of 
focusing, the way I'm describing.

Why I think releases are important
----------------------------------

We haven't really done "releases" of the OpenHatch code -- when 
things look good, we just deploy the "master" branch. But that 
means it's been hard to answer users when they ask us, "What's 
new?" Going forward, I want the project to get in the habit of 
doing more regular releases, like a "normal" open source project.

If you want to work on things out of order, that's okay too. The 
nice thing about releases with themes is that if we have community 
consensus on them, then we can identify who is interested in 
working on what sorts of things. So long as you don't break 
anything else, we would still happily accept patches that do things 
that aren't in the scope of the current release.

So what I'm thinking is three releases for the immediate future. 
Right now, the version number in setup.py says we are at version 3, 
so I came up with some thoughts for versions 4, 5, and 6.

Version 4: Transparency
-----------------------

There have been some roadblocks for these new contributors, and I'd 
say they relate to a lack of transparency on our part. To name one 
example, I'm the only (active) person who has shell access to 
linode.openhatch.org and linode2.openhatch.org, the VMs where the 
website is hosted. That means if people fix a bug and want to 
deploy, I'm the bottleneck. To name another one, I'm the only one 
who receives emails with Python stacktraces when there are 
exceptions, making it hard for others to know what bugs the site 
has. In addition, it's sometimes hard to set up our dependencies; 
to get around that, people have asked for a virtual machine image.

There's code that could use comments. Jeff W. has done a great job 
of finding those.

There is server-side stuff that could be more participatory. For 
example, even though Jack Grigg has done most of the bug tracker 
crawling work lately, the logs for the bug tracker crawls aren't 
published on the web.

I want to focus on these first because I'm really happy we have 
such a large and growing community.

Lately, I've been writing and collecting documentation at 
http://openhatch.org/wiki/Category:Hacking_OpenHatch

In this release, I want to satisfy our existing and budding 
developers' desires for information and access to the best degree 
possible. (This release will probably mean a lot of changes to wiki 
pages and shell permissions, not just code!)

Version 5: Training missions
----------------------------

John Stumpo did some great work this summer (through GSoC) in 
writing training missions -- if you've missed them, those are 
interactive tutorials for tools useful for the budding free 
software contributor. When I talk about them, people are excited 
(-:. And we've had some people visit the IRC channel to ask 
questions about them. They're online at 
http://openhatch.org/missions/.

Right now they're in "Beta", which means they're published but we 
don't really recommend people use them.

I'd love to see a HOWTO guide for writing a new mission, and we 
have some usability glitches with the existing missions that we 
could smooth out. And finally, we have to decide how they integrate 
into the website. Maybe as people finish training missions, it 
appears in the front page's activity feed. I'm not sure -- and that 
decision is probably the single biggest thing holding us back from 
removing the "BETA" banner on the training missions.

In this release, I want to really polish up the training missions 
we have and invite people to write new ones.

Version 6: Automatic adding of bug importers
--------------------------------------------

Jack has been doing awesome work on the bug tracker importers. He 
even wrote a simple web interface to let project admins add bug 
trackers automatically. It lives in the "next" branch.

I want to have versions 4 and 5 done so that we can focus on 
getting that going. It would be totally awesome if we can stop 
telling projects to add sections to the wiki, but instead let them 
add bug trackers and then watch them get crawled automatically.

In this release, I want to make it super easy for people to add 
their projects' bug trackers to be crawled by OpenHatch.

The Distant Future (like, October, hopefully)
---------------------------------------------

I think it'd be great to have one more tech-focused release. In 
particular, I want one focusing on performance and scalability (the 
map is famously slow, and the whole site could be a bit snappier).

Then we can get into some feature-focused releases, like a release 
focused on making the OpenHatch site more useful for projects that 
want to mentor new contributors. (Maybe we need to add (or 
remove?!) some features for them.)

What do you think?

Do you folks like the idea of doing a push for Version 4, focused 
on transparency, and then versions 5 and 6 focused on the training 
missions and automatic bug crawling?

If this sounds good, say so. If not, say so! And we'll reach 
something like consensus and move forward. (-:

P.S. Thanks to people on #openhatch for helping me figure out what 
I wanted to say here.

-- Asheesh.