**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 <http://bugs.foocorp.net/issues/368>`_
   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.