This is an interesting idea, but I'm concerned that it will be a bit unintuitive to everyone and confusing for any new developers. Also, in the case of enlightenment, there is already a separate project for each release, so this means there would be even more projects to look through. Do you have any thoughts regarding this?
On Sun, Dec 6, 2015 at 10:12 PM Carsten Haitzler <ras...@rasterman.com> wrote: > On Thu, 03 Dec 2015 22:29:14 +0000 Mike Blumenkrantz > <michael.blumenkra...@gmail.com> said: > > actually i was thinking. this isn't the right way to do this. actually > wishlist > priority is not the right way either. > > this kind of screws phab's ability to drill down to actual bigs when we > release. the burn rate stuff doesn't work nicely because todo and wishlist > items > are included in bug count. > > https://phab.enlightenment.org/maniphest/report/burn/ > > this specifically > > when you filter by project you get wishlist and now todo included. > > i dont think we want that. > > what i think we want is something like > > projectname > projectname-todo > projectname-wishlist > > where we assign the todo and wishlist bugs TO a specific project that is > the > project todo and wishlist "list". > > this should work much better imho. > > ... ? > > > In other projects that I've worked on, bug trackers sometimes tag tickets > > based on various attributes. An example of this is the Servo project on > > github: > > > > https://github.com/servo/servo/issues > > > > Tickets here are tagged by component, type of ticket (bug, refactoring, > > enhancement, ...), and difficulty. > > > > We've been getting some newer developers recently, both corporate and > > hobbyist, and I think some of this tagging could be useful to our > > workflow--specifically tagging tickets for difficulty. > > > > What this would require is the creation of projects like "Trivial", > "Easy", > > "Hard", "Wizards Only", etc, and then adding these projects to tickets. > In > > this way, someone with knowledge of the related area for a ticket could > > mark some tickets out which could then be handled by people with the > > related level of expertise/stubbornness. > > > > Ideally, this would somewhat reduce work for our more senior developers > by > > making easier tasks more visible. It would also enable new developers to > > find tickets which they could make progress with while avoiding falling > > into evas_map and other bug abysses. > > > > If this goes well, it may be worthwhile to also start tagging/creating > > tickets for "todo" items using the same methods. > > > ------------------------------------------------------------------------------ > > Go from Idea to Many App Stores Faster with Intel(R) XDK > > Give your users amazing mobile app experiences with Intel(R) XDK. > > Use one codebase in this all-in-one HTML5 development environment. > > Design, debug & build mobile apps & 2D/3D high-impact games for multiple > OSs. > > http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 > > _______________________________________________ > > 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 > > ------------------------------------------------------------------------------ Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
