add repo-type to identify the type and purpose of the repositories #53
Conversation
|
Could you also have something to distinguish between one repo for one spec, or one repo for multiple specs? The proposal seems to imply one specification per repository and it is not always the case. |
|
we discussed the idea of adding support for "one repo for multiple specs" but we stopped since we didn't know how useful this would be. For example, if you say "rec-track", the IP manager knows enough to track contributions. |
|
if you have rec-track docs and a wg note (not on PP), how do you track only the relevant contributions? |
|
the idea is to use the more important one. If your repo contain a REC-track doc and a non-REC-track one, we need to worry about the REC-track one first, thus you'd use "rec-track". Yes, the IP manager will flag pull requests for non-REC track docs but, until we revise the IP manager, there is no way around, independently of the w3c.json. |
|
Fair enough, could it be a RFE for the next iteration of it? |
|
yes, definitively. We didn't a showstopper in the current proposal to add support for multiple content in a one repo in the future. |
There was a problem hiding this comment.
I'm okay with this extension to w3c.json (but see comments inline).
Thinking of repos containing software, yes, we need a way to identify them. I don't mind whether that is because they will never include a w3c.json file, or because they will have it but it will contain some specific value in the field repo-type.
About repos used for more than one spec: I thought we mostly discouraged those. Automatic publication as part of CI, for example, becomes more cumbersome and complex to maintain. Are you aware of many repos like that?
w3c.json.html
Outdated
| <strong>Note:</strong> If the group is actually a joint task | ||
| force of more than group, please specify all the IDs of the | ||
| groups consist of the task force as an array, e.g.:<br/> | ||
| "group": ["35422", "83907"] |
There was a problem hiding this comment.
- Wrap this line of JSON in a
<pre>, as in the example above. - If we expect numeric IDs, and the example above uses a
numbertype (not astring), these IDs here should benumber, too (ie, remove the quotation marks).
There was a problem hiding this comment.
OK
I'll wrap the example line with "<pre>".
Also I'm fine with using "number" (=removing the quotation marks).
|
(Pinging @deniak explicitly to get his comments; specifically about the field |
|
+1 on promoting one spec per repo.
I suspect we could make a split for some but not all, eg csswg-drafts. |
|
re repos with multiple specs under different IPR regimes in the repo manager, there is already an open issue on this fwiw w3c/ash-nazg#125 |
This shouldn't be a problem for Echidna. It can already deal with multiple deliverers. |
|
it would be good to identify non-TR documents. I wonder if that goes under "note" or a new one. The EO WG is producing a lot of articles on GH and we should integrate that fact into our tools. |
Based on the discussion with Philippe and Dom, I've added an additional field to identify the type and purpose of the GitHub repositories: "rec-track", "note", "cg-report", "process", "homepage", "tool", "project" and "others".
Also added a note that we can use an array to specify multiple groups when the target group is actually a joint task force which includes more than one group.