Changes between Version 1 and Version 2 of WikiGuidelines

Apr 1, 2008 10:04:44 PM (8 years ago)


  • WikiGuidelines

    v1 v2  
    77Otherwise, some guidelines to keep in mind:
    9 == The wiki and Tickets ==
     9== The wiki ==
    1111No Discussion on the Wiki!  Keep discussion on the mailing list and
    1212use the wiki to document consensus and pros & cons.  It is just fine
    13 to have conflicting points of view in a ticket or on the wiki, but no
     13to have conflicting points of view on the wiki, but no
    1414back-and-forth discussion (use the mailing list for that).  Create
    15 "pros" and "cons" sections in the ticket/wik.
     15"pros" and "cons" sections to document both sides of the discussion.
    17 == For Tickets ==
     17== Tickets ==
    19 For tickets, use EDIT rather than adding "comments".  Link this ticket
    20 with wiki pages or other tickets which are related, or for which this
    21 is a counter-proposal.
     19We have been using tickets in the past to keep track of proposals, but that turned out to be rather cumbersome as there are many small issues.  So now the status of each proposal is kept in the Haskell source file [] which can be modified by committee members, and from which the wiki page [wiki:Status] is automatically generated.
    23 Be sure to set the "component" field as "Proposal" and leave the Adopt
    24 field alone.
     21== Creating a proposal from a discussion ==
    26 == Creating a Ticket from a Discussion ==
    28 So for instance, there's a proposal that we modify the comment syntax.
    29 After some time for discussion on the list, whoever is agitating
    30 (leading a discussion) should create a new ticket if s/he still
    31 believes in the suggestion.  The ticket should have
    32 component:proposal. The pros are that it's going to be simpler for
    33 students, more consistent with the block comment syntax, and easier to
    34 implement in editors.  The cons are that we lose a group of possible
    35 operators, --> for instance, and this in turn may cause some code to
    36 break.
    38 Put your email address on the tickets so we know who to ask if we have
    39 any questions.
    41 To create a ticket, go to the wiki and log in.  The user name is guest
    42 and the password is haskell'.  If you think you'll be doing a lot of
    43 ticket work, email me for a guest account so that your name will
    44 automatically appear on the changes.
     23It is the responsibility of the committee to keep track of proposals discussed on the mailing list.  If your idea has not been made into a fully-fledged proposal, please notify a committee member and ask them to do so.