Requests for Units

Act only according to that maxim whereby you can at the same time will that it should become a universal law. Immanuel Kant

This is the routine maintenance work for UCUM.

In a typical year we see no more than 10 requests for additions to UCUM.

However, many of the requests are problematic and require careful consideration balancing the semantic clarity of UCUM units with the practical demands of users in the field.

Because UCUM must be a system based on principles and cannot under any circumstances be allowed to become a grab-bag of vaguely defined words, all decisions on new entries must be based on principles.

The present hot topic to be resolved is the ProcedureDefinedUnits.

The mechanics of request processing is as follows:

1. user signs up to the web site.
   • pass the captcha,
   • the email verification may currently cause an error
   • the new user is still active and can log in.

2. user enters New Ticket for request
   • the most common question we need to ask back is: please provide a literature reference (or attachment) which provides a scientific definition.
   • a scientific definition is a quantitative one, not just words "unit for the amount of XYZ"
   • a scientific definition will give some way of converting or inferencing something with the values expressed using that unit.

3. a board member reviews the requests
   • drafts a quick except of the essence of the request and proposes one of the determinations:
     1. accept, in which case the board member will be the owner and make a concrete change proposal to the standard.
     2. 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
        1. reject. Next status will be 'wontfix'
        2. reconsider. Next status will be 'reconsidered'
   • all decisions should be made with adequate actionable comments
     • accept -- should state exactly what should be added to the document
     • reject -- should explain why
     • reconsider -- should explain how the original request could be fulfilled
       • the emphasis is on how not just why

4. first time users making a request will have a limited status to provide input.
   • based on the quality of the request, the administrator can add the role "verified" to the user.
   • verified users are granted more privileges to discuss content on the web site.
   • 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.