On Fri, 11 Dec 2015 15:39:57 +0000 Mike Blumenkrantz <michael.blumenkra...@gmail.com> said:
> On Wed, Dec 9, 2015 at 12:36 AM Carsten Haitzler <ras...@rasterman.com> > wrote: > > > On Tue, 08 Dec 2015 14:16:39 +0000 Mike Blumenkrantz > > <michael.blumenkra...@gmail.com> said: > > > > > 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? > > > > yes - fro e there are projects per version. tbh this is a bit confusing > > too as > > people often assign to the wrong project or it's still a bug in matser and > > was > > there in e18 etc. - so similar thing. but for todo - the developer doing > > the > > todo i think can handle it. it shouldnt be confusing for a developer to > > use the > > right project - they should know their way around. > > > > as for wishlists submitted - we end up having to triage them in the end > > anyway > > and change priority to wishlist from the default value, and isn't this the > > same > > as just changing the project it is assigned to, if we are changing priority > > anyway? > > > > also bonus - if we have a project for these... we can have different > > priority > > wishlist items - those that are more important/cool/useful and those that > > are > > less... :) now we can have no priority of wishlist or todo items. > > > > After considering this for a couple days, I think I may have a good > compromise. Instead of having $project-wishlist and $project-todo, it seems > like it should be easier to just create overall "Wishlist" and "TODO" > projects. Then the associated project repo can be added as a secondary > project. > > For users, this means that they can just file it attached to a project and > it becomes easy to tag it with an additional project while having a > reasonable chance that the initial submission goes to the right place. > > For developers, searching overall for wishlist/todo tickets remains just as > easy, and paring it down to a certain project is also easy. though then the bug stats show wishlist and todo items for that project as a number, so at a glance and the graph won't tell you things like "look we have fixed almost all the bugs now for elementary - it's only todo/wishlist left!" ie - number would hopefully be near 0. ? is this just trying to have developers avoid looking at multiple projects? you have been doing this for enlightenment for a while (assigning bugs per version with each version a new project in track) so ... was this unsustainable for you? phab does do auto-complete lists as you type, so typing in efl will list efl, efl-todo, efl-wishlist and so it's easy enough to not miss them... or to select them without full typing... ? > > > 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 > > > > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
