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

Ryan Sleevi sleevi at google.com
Wed Nov 4 01:18:12 UTC 2015


Kirk,

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 <
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?
>

No.


>  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,
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? :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151103/4dde0dad/attachment-0003.html>


More information about the Public mailing list