[E-devel] Phab EFL ticket management

[Andrew Williams]

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

[jaquilina]

I would be willing to test and triage bugs if need be. Also I want to propose a method that libreoffice uses and that is of what they call easy hacks.
They are classified according to complexity and would be a good way to encourage new developers to join and a good way for them to get used to the code Base. 


Sent from Samsung tablet.-------- Original message --------From: Andrew Williams <***@andywilliams.me> Date: 15/07/2017 22:12 (GMT+01:00) To: Enlightenment developer list <enlightenment-***@lists.sourceforge.net> Subject: [E-devel] Phab EFL ticket management
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-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[Cedric BAIL]

Hi,

Post by jaquilina
I would be willing to test and triage bugs if need be. Also I want to propose a method that libreoffice uses and that is of what they call easy hacks.
They are classified according to complexity and would be a good way to encourage new developers to join and a good way for them to get used to the code Base.

That is indeed a good idea. I don't know how to do that in phab, but
would be good. Another possibility is for beginners to help in
debugging and narrowing down where the problem come from. netstar for
example has been of amazing help in that regard. So just saying that
improving bug report is also very useful.

Post by jaquilina
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
* 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 :)

Sounds like a neat idea to me !

Post by jaquilina
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 :)