[Devel] Our three next releases

[J W]

Sorry, belated reply, just finished moving to my new place and by
happy stroke of luck I have wireless.


> We haven't really done "releases" of the OpenHatch code -- when
> things look good, we just deploy the "master" branch.
What's wrong with that? I like instantly deployed features. Having to
wait for a feature to be deployed because of an arbitrary label being
applied to it seems counter productive especially for a new and
growing website.
> But that
> means it's been hard to answer users when they ask us, "What's
> new?"
What's so hard about doing a 'got log'?
Sure some people aren't devs and wouldn't know about that, but what's
wrong with an rss feed of the last 5/10/20 commits to the code base?
:)
> Going forward, I want the project to get in the habit of
> doing more regular releases, like a "normal" open source project.
Fair enough but I would point out that while openhatch is an open
source project, it's also a website.  Which is more important? Not to
create a false dichotomy, just making sure we keep it in mind.
> 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.
One of the best parts of that would be that I or anyone else keeps
working on whatever they want to, and it's up to you to coordinate the
release with everybody. Hmm, well it's a pro and a con I think.
>
> 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.
Why would anyone else need access?
Do you really trust anyone else with access? Frankly, I wouldn't.
Maybe I'm just an untrusting person.  I mean, the codebase is already
open and available for anyone else to implement their own openhatch,
are you intending to make _access_ to your server open source as well?
O.o

I understand and agree with your concern about the bottleneck, but I
think the solution requires more trusted parties instead of being more
lenient about who to trust, if that's even what you were suggesting at
all.

>  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.
Where do the stack traces come from? Users with problems or the server
itself emailing you it's problems when it has them? You could send
both to the mailing list I think. At the risk of decreasing the signal
to noise ratio. Perhaps a separate list?


> In addition, it's sometimes hard to set up our dependencies;
> to get around that, people have asked for a virtual machine image.
Improved documentation would also fix that, and wouldn't require
someone to update and republish the VM whenever a hange was published.
 Not that I'm against the vm, I like the idea. Just sayin.

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

Haven't I though? :) lol

> 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.

That'd be cool.

> 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/.
I think the missions can really help out new developers. I think we
should encourage people to write more of them.
> Right now they're in "Beta", which means they're published but we
> don't really recommend people use them.
Puh-shaw! Beta just means 'your helping us find bugs', it doesn't have
to mean don't use it yet.  I think we should direct as many people to
them as it takes to get rid of the bugs.  Perhaps marking the ones
that are known to work as 'out of beta' ?
>
> 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.
I like that idea, its close to the achievements suggestion, trying to
make it more appealing to do missions by gaining some kind of
arbitrary social standing statistic.
>
> 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.
This I have to see..
>
> 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.
Openhatch doesn't do github or ticgit or ditz yet. This makes me sad
on the inside. ;-)
>
> 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).
Understatement of the century. Love the site but sometimes I pull hair
out waiting for it to load.
>
> 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?
On the whole it sounds good.
>
> 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.
> _______________________________________________
> Devel mailing list
> Devel at lists.openhatch.org
> http://lists.openhatch.org/mailman/listinfo/devel