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
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: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nomeata@joachim-breitner.de
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs