Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802SEC] MyBallot and MyProject improvements


On 303//11 11:07 AM, Pat Thaler wrote:
Dear Colleagues,

I'm working on my action item to compile a list of My Ballot and MyProject issues and feature improvements.
Please send me any items that you have.

It is good that you are doing this. However, there has been no shortage of requests for bug fixes and feature improvement over the years. What has been lacking is a significant commitment from SA management to improving, supplementing and/or replacing myBallot. I am distressed that SA does not seem to have in place an ongoing management tool for tracking requests of this sort.

In my mind, there are two major high level problems:
- myBallot is a poor implementation of a system that is obsolete in most of its design aspects. Thus one aspect of the list you request would be to supply items to "fix" the system that we have.
      I'll supply my items for that list under the heading "Category I"
- We have enough experience under our belts (almost 20 years at this point) with comment handling systems and systems capabilities have improved enough in the meantime that it is time to think what a "modern" balloting system should look like. I'll supply my items for that list under the heading "Category II".

In addition, we have the age old problem of the differnce of views on commenting in the SA vs. 802. In the SA, the only reason for a comment is to express a reason (they tend ot think of it in the singular) that a balloter is voting against a draft. Although approve comments are allowed (I suspect because it is an ANSI requirement) there is nothing in the P&P about dealing with them other than "They must be considered." How an individual comment is handled is hardly dealt with. The 802 model is that comments are king and who submitted them is secondary. Comment resolution is the tool for document improvement and for judging when a draft is ready for approval. The emphasis is on quality of output rather than satisfaction of the participants. I believe that is a good thing.


1) myBallot qualifies comments at upload time instead of at input time.
2) The quality of the error messages for input format errors is terrible. They are almost completely useless for assisting the naive user in actually repairing what myBallot classifies as input errors. 3) myBallot seems to be far fussier than it needs to be about input errors. Many errors that it rejects would seem to be harmless to just go ahead and carry in the database (e.g. a leading space). 4) the myBallot database needs to include all comments on a given project, not just the comments from a given ballot. This should be done so that Revcom can see all comments and that the BRG can manage resolution of comments across the full balloting cycle. Comments should be each given a unique identifier per project rather than per ballot cycle. 5) myBallot needs to have a method to reference comments as well as text locations in a draft. Comments and their resolution rationale are fair game for recirculation comments in addition to the resulting text in the new draft or lack thereof. 6) In a database than spans multiple ballots and recirculations there will need to be a number of control fields added that indicate whether a comment has been recirculated and whether it is still in-scope or out of scope at a particular circulation of a ballot. 7) The pain that it takes to manipulate a myBallot spreadsheet is an unreasonable burden to put on the volunteers who are on RevCom or who do comment resolution. It is inexcusable that the SA is not providing access to the more advanced tools like those that some WGs have had available for years. The NIH factor plus the lack of use understanding on the part of the staff in the SA seems to be a major obstacle to process improvement.

(I believe that staff should be required to use myBallot to comment on their governance documents (e.g. changes to P&P). If staff (at all levels) were actually exposed to the crustiness of myBallot then the resistance to change would diminish.)

Category II

It's time to start moves to a next generation commenting tool. The business of manually entering the reference point from one document manually into another document is not appropriate to the current technology of software. A balloter should be able to point to a character or range of characters in a draft and have a comment entry window open. When a comment is entered in such a way there should be a mark left behind which is a link to that comment (in a variety of forms depending on the "mode", e.g. comment entry, comment resolution, ballot process auditing, etc).

When comments are gather and rolled up into the balloting database, the comments again should accessible from the draft as well as more conventional reports. Such a tool should have the capability to drive multiple displays/screens at once as well as having tile and toggle modes.

A second generation tool should also have better support for dealing with macro issues and grouping comments that (a) a strict repeats from different voters (e.g point out errata) or (b) deling with a same or similar issue.

And finally, it is obvious that the use case for balloting systems demands a change system that is much more nimble than the one we are alleged to have. That need is obvious for a number of reasons.

I hope this helps you in your task in addition to the other excellent suggestions that I have seen. I note that I haven't seen any input yet from Roger on this topic. Thus we don't seem to have his long standing request on the list for the comment fields to be able to handle formatted text (especially bold, italics, underline, and strikethrough) rather than just (limited) ASCII.

Best regards,

This email is sent from the 802 Executive Committee email reflector.  This list is maintained by Listserv.