Opened 13 years ago

Last modified 9 years ago

#106 closed task (FIXED)

requesting feedback on how to think about and use this tracker

Reported by: Caleb Davis Owned by:
Priority: minor Milestone:
Component: infrastructure Keywords:
Cc: Parent Tickets:


**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!

Change History (5)

comment:1 by Caleb Davis, 13 years ago

oh yeah, and there may be times when the stages don't occur in the
given order, *eg* we think we need some kind of message queuing and
we immediately find a cool package, then we work on the design,
then we code. It's hard to imagine coding without resolving either
design or implementation, but maybe I just need to hone my
stream-of-consciousness coding abilities :P

comment:2 by Caleb Davis, 13 years ago

Status: NewClosed
This level of organization may be a good idea down the road, but
for now it seems like too much structure to force upon ourselves,
and could distract from getting stuff done. I'm closing the ticket.
Feel free to open it back up should you have any feedback.

comment:3 by Elrond, 13 years ago

Component: Infrastructure

comment:3 by Elrond, 13 years ago

Also we already have bug `#371 </issues/371>`_. This goes in an
alike direction.

comment:4 by Will Kahn-Greene, 12 years ago

The original url for this bug was .
#85: related

Note: See TracTickets for help on using tickets.