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 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.
