+1 On Sun, Oct 25, 2015 at 11:57 PM, Shuai Lin <linshuai2...@gmail.com> wrote:
> +1 > > On Wed, Oct 21, 2015 at 12:55 AM, Greg Mann <g...@mesosphere.io> wrote: > > > +1 > > > > On Tue, Oct 20, 2015 at 9:50 AM, tommy xiao <xia...@gmail.com> wrote: > > > > > +1 Yes please! > > > > > > 2015-10-19 16:09 GMT+08:00 Alexander Rojas <alexan...@mesosphere.io>: > > > > > > > +1 Yes please! > > > > > > > > > On 15 Oct 2015, at 10:11, Bernd Mathiske <be...@mesosphere.io> > > wrote: > > > > > > > > > > Proposal: in extension of today’s limited two-level (epic, task) > > > > approach, make full use of expressive power already available in JIRA > > to > > > > provide more structure for larger projects to facilitate planning, > > > > tracking, and reporting. This will facilitate dynamically planning of > > > > sub-projects, which will make us more agile. > > > > > > > > > > The general idea is to use links between epics to provide a > recursive > > > > hierarchical structure, with which one can span trees or DAGs of > > > > arbitrarily large projects. This does not mean that we want to plan > > > > everything in minute detail before starting to work. On the contrary. > > > > > > > > > > You can start anywhere in the eventual tree and express part of the > > > > overall effort, maybe say a short epic with a few task tickets. Then > > you > > > > can LATER make this epic a dependency for a larger effort. > > > > > > > > > > Conversely, you can subdivide a task in the epic into subtasks. > > > However, > > > > this does not mean that you have to literally use the feature > “subtask” > > > in > > > > JIRA for this. Instead, staying recursive in our JIRA grammar, so to > > > speak, > > > > convert the task to an epic and then create ordinary tasks in it to > > > > represent subtasks. > > > > > > > > > > Now the task cannot be a task in its parent epic anymore. We fix > this > > > by > > > > putting in a link of type "blocks" to the parent. When you then look > at > > > the > > > > parent, it still holds a number of tasks, and it has one dependency > on > > an > > > > epic (to which you can add more). > > > > > > > > > > Thus our dependency tree can grow in all directions. You can also > > > > rearrange and update it in any shape or form if necessary. > > > > > > > > > > Overall, we only use two JIRA elements: epics and tasks (of > different > > > > flavors such as bugs, improvements, etc.). Tasks are the leaves, > > > everything > > > > else is an epic. Review requests only ever happen for tasks. > > > > > > > > > > The epics are there to provide a high level view and to allow > dynamic > > > > (“more agilish”, non-waterfall) planning. Granted, you’d also use a > > tree > > > if > > > > you did waterfall. The difference is that you’d spec it all out at > > once. > > > My > > > > observation is that not too few of us do exactly this - outside JIRA > - > > > and > > > > then try to remember what tickets are where in their tree. Let’s make > > > this > > > > part of JIRA! > > > > > > > > > > Why not use labels? Because they are in a flat name space and we > want > > > to > > > > represent tree structure. How would you know that a label denotes a > > > > subproject of another label? By memorizing or by depicting a tree > > outside > > > > JIRA. Why not use components? Same problem as with labels: flat name > > > space. > > > > We can use labels and components these for many other purposes. > > Separate > > > > discussion. > > > > > > > > > > Aren’t we doing this already? Probably. I have not checked > > thoroughly. > > > > There may occasionally be epics that link to other epics. If so, I > > would > > > > merely like to encourage us to use this powerful expressive means > more > > > > often. > > > > > > > > > > Bernd > > > > > > > > > > > > > > > > > > > > > > -- > > > Deshi Xiao > > > Twitter: xds2000 > > > E-mail: xiaods(AT)gmail.com > > > > > > -- Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer Platform Symphony/DCOS Development & Support, STG, IBM GCG +86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me
