Wiki: special namespace for proposals?

[Andrew Farmer]

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