Hi, In a word no. What that is is an ever growing list of work we would like to get done. That's not really a planning tool it's a log. Planning for what goes into a release is a different beast - we make a list of what's required, agree on it and start working through.
Surely in planning for a release you need either a) a delivery date and a prioritised list or b) a requirements list and an agreed scope. A list of things that gets added to as we work through is not either of those - the list could grow forever and never get finished... Andy On Mon, 21 Aug 2017 at 11:41, Carsten Haitzler <ras...@rasterman.com> wrote: > On Sat, 15 Jul 2017 20:12:34 +0000 Andrew Williams <a...@andywilliams.me> > said: > > just saying... isn't > > https://phab.enlightenment.org/T5301 > > good enough? i mean it does what's needed. tacks a todo list and even > dependencies... etc. > > > Hi team, > > > > As many would probably agree by now we have a very high ticket volume > which > > is rather hard to manage... Whilst folk are doing a great job of > > marshalling the incoming tasks I think that some more structure would > help > > us to see what is needed in each area and for the next release etc... > > > > In preparation for 1.21 I would like to start working on this a little to > > help us manage the work for our next release (especially as it will be > the > > eo interfaces release!) and propose to do the following in phab, as it is > > otherwise managing to keep track well: > > > > * Add a milestone to efl phab project for the next release - this will be > > used to mark the issues we have agreed must go into the next release > > * Add sub projects for each area of EFL so we can better categorise the > > tasks (we can either use EFL or a "common" subproject for those that > apply > > to all > > * efl-eina > > * efl-eolian > > * efl-canvas > > * efl-canvas-layout > > * efl-ui > > (etc etc) > > > > Notice the use of the new namespaces for everything in the interfaces - > > this is surely how we should be thinking going forward :) > > If we are able to split things out a bit more then we can have more > people > > assigned to projects with fewer issues per project. > > Then the milestone for release can be the main point of concern for a > > release manager :) > > > > I wanted to throw the concept out to the list before doing anything in > case > > there are any concerns with this approach that I may have missed? > > > > Thanks :) > > Andy > > -- > > http://andywilliams.me > > http://ajwillia.ms > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > -- http://andywilliams.me http://ajwillia.ms ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
