Re: Moving the process to github…

On 12/27/2016 10:15 PM, Jeff Jaffe wrote:
> [
>> 1. What about where github is blocked?
>> This has been reported as being the case for various W3C member organisations, based on policy at various different levels.
>> Has W3C done any systematic investigation to determine the scope of the problem, and how affected stakeholders can continue
>> to participate?
>
> We have not done any systematic investigation.
>
> Indeed, as you point out, there are some Member organizations for whom github is blocked.  But we have not heard this
> complaint from a large number of Members.
>
> Github being blocked has not inhibited many Working Groups from using it.  Since these groups typically have broader
> participation that W3C Process - I doubt that this should be the primary reason for W3C Process not to use github.

This is the first I've heard of this, and it's somewhat concerning to me.

In the case of the CSSWG, we do have
   a) Public drafts on /TR and editor's drafts on drafts.csswg.org
   b) A public, archived W3C mailing list which historically has,
      and can continue to, accept feedback
   c) A public, archived W3C mailing list archiving all GitHub discussions
   d) A read-write mercurial mirror of the git repos on hg.csswg.org
so it is possible, though perhaps a bit awkward, to follow and participate
in the CSSWG's work without access to github.com. I'd expect the Process
group to set up similar infrastructure. I will note however, participation
without access to GitHub wasn't the motivation for us--the existence of
historical infrastructure and a desire to maintain archives beyond the
demise of GitHub was--so we haven't audited the viability of GitHub-less
participation, and there are no coherent instructions...

Are these Members blocked at the organization-network level (which is
annoying but tolerable), or a national level (which means we have a
W3C-wide accessibility problem wrt all groups using GitHub)?

> . Producing coherent drafts?
> While the document has been in Mercurial, I have attempted as editor
>to provide periodic updates that are a coherent draft, including a
>relevant status section, a written change log describing the substantive
>alterations in drafts, and more recently a diff-marked HTML document to
>highlight changes between the current editor's version and the currently
>operative process. How much of this is worth continuing to do, and how
>do we make it happen, given the workflows of github?

Mercurial and Git provide equivalent infrastructure as far as diffs go,
so any considerations here would not be affected by a change to GitHub.
One thing that does help a lot, though, is following
   http://rhodesmill.org/brandon/2012/one-sentence-per-line/
(Or rather, “one sentence per phrase” since our sentences do tend to get
quite long sometimes ;) Tab and I have adopted this for all our specs.

Personally I value the creation of coherent drafts and changelogs, and
HTML diffs where appropriate [1], so as a spec editor I've put in the
effort to produce these (even though sometimes it's kindof annoying :p)
Public VCS is useful and important, but it's imho not a perfect substitute
for a human-generated review of changes.

[1] As an example, Flexbox provides an extremely detailed changelog over
     the course of its CR phase, since this helps implementers notice and
     understand what's changed, and therefore what they need to update in
     their implementations. https://www.w3.org/TR/css-flexbox-1/#changes
     (My changelogs for less stable and complicated specs tend to be more
     high-level and omit the diffs.)

~fantasai

Received on Wednesday, 28 December 2016 09:00:44 UTC