[cabfpub] Ballots 154 and 155 - Convert to RFC 3647 Framework and GitHub

kirk_hall at trendmicro.com kirk_hall at trendmicro.com
Wed Nov 4 01:40:37 UTC 2015

Actually, Ryan, no – my concerns were not addressed, the were basically overlooked and never resolved.  They remain the same.

I have no problem if someone (Ben?) wants to maintain the “official” version of these documents in GitHub, but these documents are also used by many (non-technical) people in our organizations and around the world.  So as a practical matter, they must also be available in open standard formats such as pdf and .doc.

Ben – can you address my original questions more specifically (see below) so we can all understand your intentions in these ballots?

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Tuesday, November 03, 2015 5:18 PM
To: Kirk Hall (RD-US)
Cc: Ben Wilson; CABFPub
Subject: Re: [cabfpub] Ballots 154 and 155 - Convert to RFC 3647 Framework and GitHub


I appreciate your repeated concerns. However, I will note that these have been addressed for you both in Zurich and Istanbul. I can understand the concerns of switching to a new system, but I do hope you can approach this with an open mind, and see how your request, while seemingly simple, is actually an unreasonable burden that you're asking others to bear.

On Tue, Nov 3, 2015 at 4:07 PM, kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com> <kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>> wrote:
Ben – would you consider adding the following sentence to each ballot?

“A version of each ballot and each document as amended by time to time by the Forum will also be published as .pdf and .doc documents for ease of use by Forum members and by the public.”

I think you have said that is the plan, but it would help build support for these ballots if we know that will happen.

As indicated, these can change w/o the need for a ballot. If your concern is that Members will "Vote No" to this process, objecting to it, the reality is that this is the purview nominally of the Webmaster, but in practice has been accomplished through the voluntary work of others. It would seem that even if you personally do not want to employ these tools (which I address below), it would be counter-productive to oppose ways that make others' lives easier at no effect to you (again, addressed below)

Also, do we need to set up expectations about who will be using GitHub?


 We only had a brief demonstration by Ryan at the Zurich face to face meeting, and it looked confusing to me (compared to the traditional way of showing changes to existing language, bold/underlined for new language, lined out for deleted language, etc.).

And Istanbul, if you recall.

Also, if I understood correctly, GitHub uses colors (red/green) to show changes – I know we have some color blind members, so that may be problematic.

This was addressed in Zurich and Istanbul, but happy to address it again: No. This is not correct.

Is it your expectation that all Forum members will get training on GitHub is they want to pull copies of documents, or propose ballots?

I'm not sure what process you're defining "pull documents" as, but our Bylaws clearly state that the Website and Public List (Section 5.2 of the Bylaws) as the place where ballots are proposed and documents hosted.

I'm fairly confident that the answer to your question is "No", given that this came up in both Zurich and Istanbul and that was the answer then, but I do want to make sure I've understood and appreciated your concern.

If so, we should discuss that before proceeding on the ballots – I don’t think that’s practical.

To put it in context for our present state of affairs, do you believe the Forum members should have training in Microsoft Office and in Adobe Acrobat? As these are both the formats you propose - and the means in which final documents were historically managed - then if you imagine this as a transition, it might help to frame the discussion by what the Forum currently requires - or doesn't.

For example, no one is required to submit an amended Word Document or final PDF as part of proposing a ballot. In that same way, as indicated in Zurich and Istanbul, no one would be required to use GitHub. Much in the same way that your ballots proposed on the mailing list 'transparently' (through the hard work of Ben and others) into final guidelines hosted on cabforum.org<http://cabforum.org>, so to would this process remains the same.

In this sense, it's worth reiterating what was mentioned at both Zurich and Istanbul - if you don't want to use it, you don't have to. It's really that simple, and hopefully that allays the concerns you have :)

Plus, will the public have access to GitHub if they want to see the documents, or copy them?

Yes, naturally. The Forum increases transparency AND security by adopting such a mechanism.

  If yes, how do we control access (it won’t be like a wiki, will it?).

No. As explained in Zurich, and in Istanbul, access control can be restricted. This was demonstrated during both meetings, and showed how you can restrict it such that only the Chair or Vice-Chair can approve changes, and the extent of any work they have to do is click a single button, and 'everything' just works.

If not, how does the public get copies of the latest ballots or the most current version of a guideline?

This is already addressed by our Bylaws (namely: the mailing list or the public website - either/or is acceptable from the POV of the bylaws, but historically we've kept ballots on the list and final guidelines on the website)

How do we train the public on how to use GitHub in relationship to these documents?

How do we train the public on the relationship between our (many-versioned) word documents that are exchanged on the public mailing list or working group mailing lists? For example, the PAG has had numerous Word documents exchanged, yet we haven't trained the public on the need to Show Comments, Show Changes, or how it works with non-Microsoft systems (such as Google Docs or OpenOffice).

I appreciate the concern being expressed for the public understanding, but I feel that's an unreasonable and misplaced concern, given both the present state of affairs and what's actually being proposed.

It might be wiser to hold back on these ballots and do some demonstrations for Forum Members first, and even try running these documents on GitHub for a few months before locking this into a ballot

This is why it's unfortunate to couple the GitHub migration to this ballot, because it's neither necessary nor required by our Bylaws.

That's not to suggest we 'just do it', but it's also worth clarifying that the opposition to the GitHub transition is somewhat unfortunate, because it's a tool that provides greater transparency, accountability, reliability, and flexibility for those that want to use it, and with absolutely zero cost for those that don't. It should hopefully be an obvious win, based on what I explained above, and I'm happy to repeat the discussions from Zurich and Istanbul if it would help you see that.

– make it separate from the conversion to RFC 3647 format (plus, I thought there was some opposition to changing the EVGL to RFC 3647 format, as virtually everything will be in Sec. 3.2 in that format?)

I'm not sure if this is a concern from TrendMicro, or just in the abstract. If it's in the abstract, wouldn't it be more useful to let those who have those concerns raise them? It doesn't seem germane as a parenthetical that seems to try to justify delaying a ballot - if it's a concern, raise it/let it be raised? :)

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151104/78610fce/attachment-0003.html>

More information about the Public mailing list