Draft proposal: JEP 2.0

[Joe Darcy]

On 04/10/2014 08:41 PM, Mike Duigou wrote:
> Some comments.
>
> Tracking:
>
> - I'll add my voice to Bob's that we want only one system of record for JEPs and that should be JBS. JEPs are either managed entirely within JBS or we shouldn't bother with using JBS for JEPS at all. If we are going to go with the many-staged workflow described in the proposal then having JBS to manage that workflow would be a huge boon.
>
> - "Alert Status (updated weekly once Funded)". This seems onerous for projects that are green (or irredeemably yellow). Required increment-the-date weekly updates has been a significant annoyance for internal processes which I would prefer not to repeat with JEPs.
>
>
> Workflow:
>
> - The diagram unfortunately reminds me too much of a LHC "Higgs Boson detection event" graphic. Many of these states are overlapping and are worked coincidentally. Since only some of them are strictly gating can we collapse the softer states to a smaller number of strictly gating states?
>

[snip]

In the JDK project of JBS, I've found the separation of Status (New, 
Open, In Progress, Resolved, Closed) from Resolution (Fixed, Duplicate, 
etc.) to be helpful when categorizing the state of a bug. (To a lesser 
extent, the separation of "understaning" is useful too.)

Perhaps an analogous refactoring could be applied to JEP state.

-Joe