Changes between Version 2 and Version 3 of RequestsForUnit

08/17/15 22:31:07 (3 years ago)



  • RequestsForUnit

    v2 v3  
    1313The present hot topic to be resolved is the ProcedureDefinedUnits.
     15The mechanics of request processing is as follows:
     17 1. user signs up to the web site.
     18  * pass the captcha,
     19  * the email verification may currently cause an error
     20  * the new user is still active and can log in.
     22 2. user enters New Ticket for request
     23  * the most common question we need to ask back is: please provide a literature reference (or attachment) which provides a scientific definition.
     24  * a scientific definition is a quantitative one, not just words "unit for the amount of XYZ"
     25  * a scientific definition will give some way of converting or inferencing something with the values expressed using that unit.
     27 3. a board member reviews the requests
     28  * drafts a quick except of the essence of the request and proposes one of the determinations:
     29    a. accept, in which case the board member will be the owner and make a concrete change proposal to the standard.
     30    b. propose_reject, next status will be 'reject_proposed', this means another board member needs to pick up the ticket and determine if he agrees with the proposal to reject. this can be
     31      A. reject. Next status will be 'wontfix'
     32      B. reconsider. Next status will be 'reconsidered'
     33  * all decisions should be made with adequate ''actionable'' comments
     34    * accept -- should state exactly what should be added to the document
     35    * reject -- should explain why
     36    * reconsider -- should explain how the original request could be fulfilled
     37      * the emphasis is on ''how'' not just ''why''
     39 4. first time users making a request will have a limited status to provide input.
     40  * based on the quality of the request, the administrator can add the role "verified" to the user.
     41  * verified users are granted more privileges to discuss content on the web site.
     42  * the timeline and most ticket info can only be seen by registered users, this is necessary and highly effective to prevent ticket spam, i.e., by removing the pay-off for a spammer to sign up to becoming a user: links they place in their spam tickets will not end up on search engines.