- From: Marcos Caceres <w3c@marcosc.com>
- Date: Wed, 20 Feb 2013 19:46:25 +0000
- To: Mounir Lamouri <mounir@lamouri.fr>
- Cc: public-sysapps@w3.org
On Wednesday, 20 February 2013 at 19:26, Mounir Lamouri wrote: > Maybe one way forward is to make sure that we get a FPWD. Then we can > add names to the document as we start getting patches for that draft > document. Again, I want to be clear that I'm happy to add anyone as > editor as soon as we have active contributions to the spec text from > them. The list of editors is by no means unchangable after the FPWD. > It's just as easy to add editors after FPWD as it is before. This sounds good, but I would like to see us establish a process for submitting patches. For example, I would like to see the specification in it's own Github repository, and, for traceability, commits only be made via pull request. This will encourage reviews of changes from the specification editors. Christophe and I experimented with this model for the Alarm API, and we found that it works quite well. See: https://github.com/cdumez/sysapps/pull/1 Where I sent him the revised text as a pull request, he reviewed and requested I fixed some things, then when he was happy as editor, he integrated my change set. This was then sent as a pull request for integration into the main sys apps repository. I would kindly ask that we decide on one or two "integrators" for the Runtime spec (or "Editors in Chief"), who are in charge of making sure that any proposed patches have been reviewed, proof read, and have consensus before being merged into the main document. Co-editors can then work off their own branches and do pull requests as they feel fit. This will also allow us to make better use of Github's issue tracker (yes, it's not great, but it will do), plus it encourages more public participation/review. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Received on Wednesday, 20 February 2013 19:47:02 UTC