W3C home > Mailing lists > Public > public-w3process@w3.org > December 2016

Re: Moving the process to github…

From: <chaals@yandex-team.ru>
Date: Thu, 29 Dec 2016 11:44:02 +0100
To: fantasai <fantasai.lists@inkedblade.net>, Jeff Jaffe <jeff@w3.org>, Coralie Mercier <coralie@w3.org>, Revising W3C Process Community Group <public-w3process@w3.org>, Ted Guild <ted@w3.org>
Message-Id: <64041483008242@webcorp01f.yandex-team.ru>

28.12.2016, 10:01, "fantasai" <fantasai.lists@inkedblade.net>:
> 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

Our drafts are currently on W3C infrastructure. I think it would be helpful if we can republish easily on w3.org - not /TR since the process isn't a tech specification. Ted?

>    b) A public, archived W3C mailing list which historically has,
>       and can continue to, accept feedback

We have that too.

>    c) A public, archived W3C mailing list archiving all GitHub discussions

I think that would be a useful thing for backup.

>    d) A read-write mercurial mirror of the git repos on hg.csswg.org

Hmm. Was that hard to set up? If we could match that on the current dvcs.w3.org repo we would have a continuous history…

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

Something like that

> 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

That's my primary goal too. But also, to help people who somehow got stuck in a time warp and suddenly want to come back and crontibute without getting totally lost.

We actually have the old member mailing address too, although I am pleased nobody has used it :)

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

Not sure. I periodically - but regularly - notice significant problems accessing Github on what seems to be a regional basis. This coul as easily be an infrastructure issue as any active blocking, but the impact is the same.

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

I have been moving the process to something like this chunk by chunk. If we're going to continue to claim diffs are readable, I guess I will do it more systematically at some point... I also use it for making source easier to search.

> Personally I value the creation of coherent drafts and changelogs, and
> HTML diffs where appropriate

Me too. I generally expect that approach to continue.


Charles McCathie Nevile - standards - Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Thursday, 29 December 2016 10:44:40 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 December 2016 10:44:40 UTC