tl;dr - I'm going to try and break up redmine tickets into three stages and record my findings here. I think it could help speed us along.

I find myself wanting to help a lot but (a) my abilities are limited at this point, and (b) it's hard to grab hold of these redmine tickets and run with them. I think we could quickly and easily break these tickets down into smaller bites, which would make our lives more wonderful in every way. I propose we use the following three ticket categories to clearly differentiate between the stages needed to complete an iteration:

• design
• implementation strategy
• coding

They each flow into the next, ie a design issue, once resolved, results in an implementation strategy issue, which when resolved would create a coding issue.

For example,

• design - the message queuing issue requires thought on multiple levels. At the top are design questions like, "how do we want the message queuing system to work, exactly? Which messages might we want to display? when? on which pages? where on those pages?"
• implementation strategy - below that are implementation strategy questions like, "is there an existing python package for this? would it be better to code a new one? What would the code look like, and where would it have to go?"
• coding - finally, there is (1)coding, (2)pushing, (3)review [goto 1] and (4)merging.

Breaking up issues into these smaller bites, ie separate tickets could speed things along. By confining the discussion to smaller areas, we free ourselves up by limiting the number of things we have to think about at the same time. Here's my suggestion - think about these categories as you are perusing redmine, and report back here with your findings. Or just follow along as I try it and give me feedback.

Or, if this problem is already solved in your mind, please point me to some reading material. Thanks!

When running mediagoblin in a subpath, like /mediagoblin/, then some things are a little complex.

For /mediagoblin/u/elrond/ request.path_info becomes /u/elrond/.

• This is good, when trying to match routes. Simple, fine, job done.
• This is BAD, when generating URLs like "request.path_info + foo" for the browser, because the browser will only see /u/elrond/foo. Which is wrong. Problem.

I know, that the environ has SCRIPT_NAME ("/mediagoblin" in this case), but it's not entirely clear, on how to procede from here.

Assigning to Chris, as he created most of the base infrastructure and surely has comments.