What are the rules for where/how W3C publications are developed?

[dwsinger]

This question arose from the Registries work. It used to be that we could assume everyone used a W3C-hosted CVS repository. Now we're mostly using Github. What are the rules that establish what you can use for development?

I suspect that we need at least:

• the ability to file bug reports (aka issues)
• history tracking (so we can see what was changed when, by whom, etc.)
• the W3C maintains a backup (so if there is a disc crash or the service goes down, we don't lose)
• the ability to register for notifications (so people and groups can 'watch' the development; summary reports are a nice to have version of this)
• the development tool/site needs to be accessible (a) to those needing accessible access and (b) to our community internationally

What else?

[LJWatson]

It should be somewhere that is recognisably W3C, so that people can trust that whatever it is they're looking at is really a W3C activity.

[dwsinger]

Thank you. Also, I think we need "anyone in the W3C membership can view the site (not restricted to a WG, for example)"

[frivoal]

the W3C maintains a backup

Yes, but I'd be more specific: a back of of the history of the document AND a backup of the issues filed and associated discussions (AND a backup of general discussions not tagged as issues, if such things exist)

[frivoal]

I'd also add a SHOULD, unfortunately not met by github:
The W3C should control the domain under which this is hosted (even if it doesn't control the underlying service) so that if the underlying service goes down, we can not only restore the content from backups, but also restore it at the original URLs, to avoid breaking incoming links.

[dwsinger]

Yes, that's what I meant by backup. I see your anxiety about the URLs. We could have redirect pointers from w3.org URLs to the repos, of course, and publish those as the official locations. That means we could redirect to a different GIT repo if needed.

So far we have:

The management system used to develop a formal W3C deliverable (technical report, in the process sense):

• must support the ability to file bug reports (aka issues)
• must have history tracking (so we can see what was changed when, by whom, etc.)
• the W3C must keep a full backup (not only the latest state, but also history, and all conversation), (so if there is a disc crash or the service goes down, we don't lose)
• must support the ability to register for notifications (so people and groups can 'watch' the development; summary reports are a nice to have version of this)
• the development tool/site should be accessible (a) to those needing accessible access and (b) to our community internationally
• may be publicly viewable, but if restricted, anyone with a W3C account (team, member, or IE) has access (not restricted to a WG, for example)
• should be clearly marked as an official W3C repository (to distinguish it from clones)
• should have an official URL that is in the w3.org domain (so that if the underlying service goes down, we can not only restore the content from backups, but also restore it behind the original w3.org URLs, to avoid breaking incoming links)

[dwsinger]

note the old Guidelines for attachments at https://www.w3.org/2002/03/email_attachment_formats.html

[dwsinger]

We need to address the question of where decisions can be formally recorded, raised in #338 . My guess is that it can be the place where discussions are recorded, and that place has to meet these rules.

[dwsinger]

This also, I suspect, intersects with the question of Minutes in #511 and #512 ?

[frivoal]

I believe this issue has now been handled, through the introduction of the https://www.w3.org/Consortium/Process/Drafts/#tooling. Agenda+ to see if we can close