On 10/8/2012 2:38 PM, Ethan Jucovy wrote: > On Sun, Oct 7, 2012 at 6:19 PM, Remy Blank <[email protected] > <mailto:[email protected]>> wrote: > > > Many of these are actually right, but most aren't worth the effort > to fix > > them immediately or at all. But closing them would also be wrong. So > > depending on the fact how you handle tickets it must not be bad, > that you > > accumulate them. As long as you at least care for these which are > > important (these, where there are requests of state, additional info - > > these where there is activity). > > Keeping tickets open that we are very unlikely to ever fix sends the > wrong message, and leads to comments like "What, this extremely > important bug is still not fixed after five years? WTF!" as we see them > here from time to time (fortunately not too often). We could close them > as "value-to-work-ratio-too-low-sorry" to make that clear, but then we > would have people re-open them with a comment like "This can't be right, > this extremely important bug must absolutely be fixed!", so I'm not sure > we would gain anything. > > > Does t.e.o have a keyword for these kinds of tickets?
I think the tickets for which we receive this sort of angry feedback are usually not the proper ones for getting started. And besides, it's not that kind of reaction which motivates us, quite the opposite you can imagine. > As a > non-core-developer I'd like to help out and also get more familiar with > the core codebase, and little bugs that aren't worth a core dev's time > to fix sound like they might be good tickets to start on. Or maybe > moving them into a special milestone would make it clear that no core > dev is likely to look at these, and also make them easy for someone like > me to find? *That* kind of tickets corresponds to the "bitesized" ones. We have quite some of them already (48 as of today). > > Along the same lines, does t.e.o have any way for a non core developer > to mark a ticket "has a patch, which works, [ideally has tests,] and > "just" needs a core developer to review the patch? These are the ones with either "[patch]" in the summary, or those having the "patch" keyword. As Dirk said, the first form is common practice, but we rather recommend the second. See for example the queries that use this keyword in TracDev/ToDo. Quite close, we have the tickets with the "review" keyword, when the patch (or the topic branch) would benefit from peer review. And you don't need to be a TracTeam member to point out the subtle (or even obvious) flaws in our code ;-) See http://trac.edgewall.org/wiki/HowToContribute#CodeContributions > > I might be misunderstanding the nature of these tickets though ... I'm > hoping you're talking about little bugs that aren't worth the time to > reproduce and fix, rather than little bugs that require design decisions > and new configuration settings or swappable components. :-) Like I suggested above, we have both sorts. We have those little bugs, though I wouldn't say that they aren't worth the time to reproduce and fix, it's more a question of "availability" to get at them. Those also usually won't generate loud complaints ;-) And it's good to have the problems documented and flagged as "open", see the various #KnowIssues sections, e.g. MySqlDb#KnownIssues. Closing those tickets wouldn't make the problem go away, and I think we very seldom close a ticket saying "ok, this is a bug we must live with" when the source of the problem is within our reach. For 3rd party bugs, it's another story, see milestone "not applicable". But we have the much bigger topics which are on the plate since a long time (typically #31, #1024, #2456, etc. see report {32} for example), and sometimes people in need of those features don't understand why after so many years they're still not implemented... Well, they're not implemented for the obvious reason: nobody did it (at all or in a satisfying way). So if those features haven't been implemented for 5, 6 or more years, why not just acknowledge they'll never be implemented? Because that's not true, they eventually will. Not all of course, but some, and it's hard to tell which, as it only depends on people turning in and being motivated enough to push them. Just look at report {33} for evidence. The latest entry there is #1942, created August the 19th *2005*, and thanks to the patient effort of many people, contributors and team members alike, it's finally there (for 1.1.1). That's ... 7 years. And it's by far not the only example. Most of the "long timer tickets" are still open because they fit well in the long term vision of what Trac should (or could) become. We'll eventually get there, or at least continue trying to get there ;-) These are the tickets on one of the mid-term milestone ("next-minor-0.12.x", "next-stable-1.0.x" and "next-dev-1.1.x") as well as the ones on the long-term milestone (which had many names, "1.0", "2.0", now "next-major-releases"). The ones on the short-term milestones ("0.12.5", "1.0.1" and "1.1.1") are already very close to be part of the software itself. We also have the special milestone "unscheduled", which is for tickets advocating features or approaches we currently consider to *not* be fitting that vision, or that they should at first better be implemented by plugins, or simply that they may present a great idea but we're clearly not willing to adopt it and make it our own. This doesn't mean that the idea or proposal is ruled out, simply that its proponent would have to do all the hard work for that feature by himself (and first demonstrating some real commitment to the project as a whole). I know Rémy would have preferred to "wontfix" those, but I still stand by my reasoning that this is a less harsh way to reject ideas: the door is not closed; additionally, for "wontfix" tickets, we have to justify ourselves a bit more than saying "we're not interested". Anyway this is just concerning 224 tickets, which means that they're still 631 "fitting" tickets on the other milestones [1] (as of today and notwithstanding errors in the triaging process). So for me, it's *OK* to have those 600+ tickets, it's just hinting at the *possible* future evolution of the software (and of course, only a part of it). I hope this wasn't getting too far off your original question ;-) -- Christian [1] http://trac.edgewall.org/query?status=assigned&status=new&status=reopened&milestone=0.12.5&milestone=1.0.1&milestone=1.1.1&milestone=next-minor-0.12.x&milestone=next-stable-1.0.x&milestone=next-dev-1.1.x&milestone=topic-wikiengine&milestone=topic-multiproject&milestone=next-major-releases -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
