Custom Query (29 matches)
Results (16 - 18 of 29)
|#83||fixed||update CreateProposal to include general guidelines|
see CreateProposal. Include guidelines for the community making tickets. My related email below:
| -= Some Guidelines =- | | Use the mailing list for _discussion_ and to reach a consensus. Use | the tickets to _document_ the consensus as a proposal. You may want | to post the wiki page you create back to the thread so that the thread | participants can review and edit it. If you get no support on the | mailing list for an idea, please think twice about whether or not to | create a ticket for it. | | It is just fine to have conflicting points of view in a ticket, but no | back-and-forth discussion (use the mailing list for that). Create | "pros" and "cons" sections in the ticket. Edit the ticket rather than | adding "comments". Link this ticket with wiki pages or other tickets | which are related, or for which this is a counter-proposal. | | Be sure to set the "component" field as "Proposal" and leave the Adopt | field alone. | | -= Example =- | | So for instance, there's a proposal that we modify the comment syntax. | After some time for discussion on the list, Thomas (cc'd) should | create a new ticket if he still believes in his suggestion. The | ticket should have component:proposal. The pros are that it's going to | be simpler for students, more consistent with the block comment | syntax, and easier to implement in editors. The cons are that we lose | a group of possible operators, --> for instance, and this in turn may | cause some code to break. | | Put your email address on the tickets so we know who to ask if we have | any questions. | | To create a ticket, go to the wiki and log in. The user name is guest | and the password is haskell'. If you think you'll be doing a lot of | ticket work, email me for a guest account so that your name will | automatically appear on the changes.
Ticket to track LanguagePragma standardization.