Instead of encoding the status in the URL, since we don't want URLs to change with the status of the proposal/feature changes, it sounds like we really just want something better than TitleIndex for browsing the wiki. (I've never seen a Trac wiki where TitleIndex is that useful anyway, other than to ctrl-f stuff.)
I'm not really familiar with what Trac Wiki is capable of. Is it possible to add tags/categories to a page and then make an auto-generated list of links to all pages with a given tag/category? Then local edits to a given design (changing the category from 'proposed' to 'implemented') would automatically move it around as appropriate. I think it would be helpful to have a single place from which we could browse current/past proposals. If for no other reason than to get an idea how to write one myself. On Wed, Oct 15, 2014 at 4:14 PM, Joachim Breitner <[email protected]> wrote: > Hi, > > > Am Mittwoch, den 15.10.2014, 11:06 +0200 schrieb Jan Stolarek: >> I'm all for improving organization of the wiki but I'm not sure about this >> idea. What happens when >> a proposal gets implemented? You can't just move the page to a new address. >> You can create a new >> wiki page describing the final dsign that was implemented and replace the >> content of the proposal >> page with a redirection. But that menas more mess in the wiki namespace. > > I think proposal and design pages are (or at least, could be) different > things. In a Proposal, there are alternatives, there are little details, > there are notes about dead end, possibly benchmarks or such justifying a > choice. > > Once something is implemented, most of that is not immediately > interesting to someone trying to understand the final design (i.e. to > fix a bug). So a good design page would have a structure anyway. And we > already have a namespace for that: Commentary! > > So when a Proposal gets implemented, this should be clearly noted at the > top of the Proposal page, linking to the relevant Comentary page (or > paper, if there is one, or Note in the code, if the final design is so > simple that it fits that format). The discussion about the Proposal > would still be there for those who need to do some historical digging, > i.e. when someone suggest a new implementation and we need to check if > that variant was considered in the original implementation. > > Greetings, > Joachm > > -- > Joachim Breitner > e-Mail: [email protected] > Homepage: http://www.joachim-breitner.de > Jabber-ID: [email protected] > > > _______________________________________________ > ghc-devs mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
