Changes between Version 1 and Version 2 of WikiGuidelines

Apr 1, 2008 10:04:44 PM (7 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.