Closed Bug 862010 Opened 11 years ago Closed 7 years ago
For certain pages, require changes to be approved before being published
What problems would this solve? =============================== Some pages on MDN are especially sensitive. This is especially true of landing pages and some pages that the DevHub team intends to add. Who would use this? =================== Only authors would use this feature. Readers would not be affected by this in any real way. What would users see? ===================== An author should see some interface for making a page as sensitive. Any other author that comes along should see some interface that makes it clear that the changes they make will not be published immediately, and will instead need to be reviewed and approved first. Readers should probably not see anything different. What would users do? What would happen as a result? =================================================== Authors should be able to mark a page as sensitive. Any other author that comes along should be able to suggest changes to the page, but they would not be published immediately. Instead, they would need to be approved first. This is similar to the concept of GitHub pull requests. Is there anything else we should know? ======================================
Whiteboard: [specification][type:feature] → [specification][type:feature][dev-ecosystem]
This is distinct from bug 665719, as this feature describes /requiring/ changes to be approved before they are published, while bug 665719 describes only the tools for reviewing changes (which could be used whether or not a review is required). The two features should probably work together, though. I would imagine this being a layer on top of the feature described in bug 665719.
Component: General → Editing
Priority: -- → P2
I would say that the ability for others to suggest changes would go through the annotation/comment system we have a separate bug for. This is really just part of the permissions system we need to implement, where in we would be able to set pages so that they can only be edited by users with a given privilege. Ideally the system would also let us make pages only readable by people with a given privilege at all, so that time-sensitive content could be built hidden then the switch thrown to make it visible when the time is right.
Just to try to keep this particular bug from creeping too far... (In reply to Eric Shepherd [:sheppy] from comment #2) > I would say that the ability for others to suggest changes would go through > the annotation/comment system we have a separate bug for. See also, bug 665752 > This is really just part of the permissions system we need to implement, > where in we would be able to set pages so that they can only be edited by > users with a given privilege. See also, bug 768498 > Ideally the system would also let us make > pages only readable by people with a given privilege at all, so that > time-sensitive content could be built hidden then the switch thrown to make > it visible when the time is right. See also, bug 677806.
I don't think this is a dup of bug 677806. That bug is about whether a page might be visible at all, to certain users. This bug is about supporting a review process of proposed changes. Those changes may be visible, albeit in some out-of-the-way review UI
Severity: normal → enhancement
Whiteboard: [specification][type:feature][dev-ecosystem] → [specification][type:feature][dev-ecosystem][triaged]
We haven't needed this feature for 4 years, and probably won't for another 4. There have been code and policy changes that have kept it from being a priority. KumaScript templates are sensitive, and editing should be restricted. Editing was restricted to a small group, and then moved out entirely to GitHub, which allows approval of changes with pull requests, commenting on changes, etc. etc. The "Zones" concept has many issues, and many related bugs. We've decided to deprecate the feature, and are in the process of removing it. This includes "vanity URLs" and zone-specific styling. When content does require protection, there are a few options: - Inject the content with a KumaScript macro, whose code is protected - Host on a static page, such as https://developer.mozilla.org/en-US/fellowship However, if a page should be protected, this is a good indication that it doesn't belong on a wiki. Instead, we've doubled-down on the wiki nature of MDN, adding features like page watches, quick reversion, spam banning, and restrictions on new page creation. We're also narrowing our focus to documenting the web platform. We're encouraging Mozilla groups that need control or are documenting Mozilla-only technologies to look into other documentation solutions, such as https://readthedocs.org. If document protection is needed in the future, it is better to open a new bug, with a specific example, so that a solution can be designed for the problem.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.