TAB, I am testing two alternatives for handling Open Project Special Majority Votes to approve Project Specifications and Candidate OASIS Standards. In other words, the comparable approvals to the one's TCs make today. After thinking about it, I realize that it makes sense, in either case, to have the votes on the tools used by the project, not on a central OASIS administrative account. (E.g. the way the approval of a Committee Specification is done on the TC's ballot tool.) Here are the results of my experimenting Alternative one: handle the SPV as a GitHub issue - Here is an example:
https://github.com/oasis-open-projects/administration/issues/3 - Pros: templates can be made to customize the information collected on the ballot. issue can be locked after closing. ballot is located in same repo as work being approved. receive notifications when someone casts a vote. ballot will remain accessible at the issue URL. ballot results are publicly visible. - Cons: results have to be tabulated by hand. Notification of all steps after open have to be done by hand. Non-members can cast votes. issues have to be manually exported if you want to produce a historical backup. Alternative two: handle SPV using groups.io ballot feature - Here is an example:
https://lists.oasis-open-projects.org/g/op-admin/message/4 - Pros: tabulates the votes automatically only group members can cast votes group members will be emailed when ballot is set up and when closed. issue can be locked after closing. ballot results are publicly visible. -Cons: no templates in form itself; have to make one and add it by cut & paste ballots can only be exported with a manual dump of the full message log Any thoughts, reactions, comments? -- /chet ---------------- Chet Ensign Chief Technical Community Steward OASIS: Advancing open standards for the information society
http://www.oasis-open.org Mobile: +1 201-341-1393