| | 14 | |
| | 15 | The mechanics of request processing is as follows: |
| | 16 | |
| | 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. |
| | 21 | |
| | 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. |
| | 26 | |
| | 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'' |
| | 38 | |
| | 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. |
