On Monday, May 18, 2015 at 1:17:47 PM UTC-7, figaro wrote: > > I wanted to gather some feedback as to how to reorganise the Roadmap type > wiki pages on trac.edgewall.org. These are the pages that profess to > collect information on the future direction of Trac: > http://trac.edgewall.org/wiki/TracDev > http://trac.edgewall.org/wiki/TracDev/ToDo > http://trac.edgewall.org/wiki/SeaChange > http://trac.edgewall.org/wiki/TracIdeas > > However, each of these pages convey more or less the same information, are > not particularly inviting for new contributors because of their link-farm > nature and reflect the state of the program when there were more core > developers actively involved. > > I therefore like to propose that these pages are treated as follows: > - start with a fresh page called TracDev, that has the core information > copied from each of the pages above and fits on roughly two pages > - the focus will be on narrative supported by stats, as opposed to the > other way around > - archive pages that have their information copied elsewhere > - information that is rationalised should be turned into tickets, if they > aren't already >
I'd like to address the idea of creating tickets in general. There are currently 1116 open tickets. That's an unmanageable number of open tickets. TracIdeas pages are nice because we can //concisely// capture //potential// changes without adding to the number of open tickets, many of which will stay open forever. The TracIdeas pages are only effective if developers review them every so often. I've been an offender of creating too many tickets. For example (1) didn't need to exist; it was created on a whim in order to hold some thoughts. (1) can instead go into the TracDev pages. The action on #493 (2) feels like the right approach for dealing with the massive number of open tickets. We end up with a bunch of "me too" comments in the history and likely the feature will never be added. Instead the idea can just be a bullet point on a page, users can discuss on the mailing list if they like. Similarly, tickets with small patches are opened, and either the Trac developers let them sit with a patch, or the reporter loses interest in pursuing the problem or revising the patch. I sometimes look at an open ticket and realize it will take 20 minutes or more to read and understand the history of the ticket, in order to decide whether it's fixed or can be closed for other reasons. At some point we should just decide which aren't high enough priority and toss them out. Fundamentally, I'd like the issue tracker to contain things we believe we can actually do someday, rather than a massive collection of feature requests and stale bug reports [e.g. (3)]. I'm aiming to clean up the issue tracker and close a lot of tickets in the coming months. If anyone feels this is not the right approach let's discuss here. (1) http://trac.edgewall.org/ticket/11701 (2) http://trac.edgewall.org/ticket/493#comment:185 (3) http://trac.edgewall.org/ticket/9544 > - there should still be a place to reach each of the underlying links, so > the same rules apply (rationalise where possible, else mark as archived) > and still have a coherent whole > > I like to hear any suggestions you may have. > -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-dev+unsubscr...@googlegroups.com. To post to this group, send email to trac-dev@googlegroups.com. Visit this group at http://groups.google.com/group/trac-dev. For more options, visit https://groups.google.com/d/optout.
