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