Re: [802SEC] MyBallot and MyProject improvements
On 303//11 11:07 AM, Pat Thaler wrote:
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.
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.
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
(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.)
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
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.
This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.