On the comment about the MediaWiki developer hub, there are more similarities between TracDev and the Developer Hub than there are differences. So I want to highlight only the points where TracDev can improve:
1- What is now in disparate pages on t.e.o can be accommodated in a single page: the TracDev page becomes the point of entry for the underlying pages. 2- As a corollary, the pages SeaChange, TracIdeas will disappear from the homepage; TracDev/ToDo, WildIdeas etc will disappear because either they are removed or their content is accommodated on pages we want to keep. 3- The introduction can be made more inviting and convey the scope and structure of the page better. 4- The links on TracDev can be accompanied by a one-liner that explains what information the user can expect to see. On Thursday, 30 July 2015 04:53:26 UTC+1, RjOllos wrote: > > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/trac-dev. For more options, visit https://groups.google.com/d/optout.
