Move all *-examples repos (interactive-examples, dom-examples, css-examples, etc.) into the mdn/content repo #431
Replies: 4 comments 2 replies
-
This is probably a good idea. One queue to manage will be helpful for those people who manage those repos. I don't, so it will probably make my life a little harder in terms of larger inflow of github actions. We'll need to be careful to make it clear how to build each particular set of examples that are now embedded as part of the bigger docset, and fix any macros, docs, and so on that expect the sources to be in a particular location. |
Beta Was this translation helpful? Give feedback.
-
A tangential question: Would this transition enable l10n of these examples? It seems that the structure of these examples might need redesigning to avoid duplicate contents so that l10n repos can store localizable strings only. (But I'd be equally happy to see examples localizable even if l10n repos have to copy duplicate contents.) |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
At the #writing-docs meeting today, this PR was an agenda item. The general consensus was:
Not discussed at the meeting, but i think we are in agreement from other discussions, while the Github repo may be separate from /content/, the content should be served on developer.mozilla.org or mdn.github.io, but not in 15 different locations. |
Beta Was this translation helpful? Give feedback.
-
We should move all the *-examples repos (interactive-examples, dom-examples, css-examples, etc.) into the mdn/content repo — along with all their commit histories and open issues.
The only thing that blocks us from being able to do that right now is the existing open PRs in each of those repos. I don’t believe we’d be able to move the PRs — they’d instead either need to be merged or closed first, or we’d need for the PR authors to re-open them against the mdn/content repo after the move.
Rationale: None of the maintainers with PR merge perms and issue-triage perms seem to be actively watching the issues and PRs in all the *-interactive repos, and not triaging them — as evidenced by some of the repos having unmerged (but mergeable) PRs that are more than a year old. And all those repos are just content — though specifically, code-example content rather than prose. And I don’t think any of the maintainers would actually prefer needing to watch and triage 20+ separate content repos, when they could instead just be watching one repo, with all the content in one place.
Beta Was this translation helpful? Give feedback.
All reactions