392513 - Create categories for Sandbox and Administration

Status: RESOLVED FIXED

(support.mozilla.org :: Knowledge Base Software, task)

Description

[Jason Barnabe (np)]

Per http://groups.google.com/group/mozilla.support.planning/browse_frm/thread/75679973909d048c

We should have two additional article categories:

Sandbox, for people playing around.
Administration, for things like the style guide.

Comment 1

[Chris Ilias [:cilias]]

sandbox and staging area are really the same thing. We should be turning the switch on the sandbox feature, so only certain people can make "live" edits.

Comment 2

[Jason Barnabe (np)]

I understand sandbox to be "do absolutely whatever you like" while staging is "this is stuff that's getting ready to be put live". In short, in sandbox you can delete someone's article without getting complaints and in staging you can't. Not sure that we need a whole category for sandbox or just a single page, but there's a difference.

Comment 3

[Nelson Ko [:nkoth]]

Re "Sandbox", maybe something descriptive like "Internal testing area".

Re only "certain people" can make "live" edits. Who are these "certain people", and how do contributors get themselves upgraded to this level of access? Once this switch is made, users will have to make a copy of the article (that is already in the kb) in the staging area to make further changes... I suppose staging area articles are created only as needed?

We need a naming convention for staging area articles (since page names are unique across wiki). e.g. Original Name (Staging), or Original Name* or Original Name (S).

Comment 4

[Chris Ilias [:cilias]]

Sorry for the delay. The plan, from the beginning was that people not yet deemed trustworthy, would need their edits reviewed/approved, before reaching end-users. Whether that be by having a dev/trunk version of each article and a production version, and syncing when needed; or holding edits for approval.

You know the old adage about Wikipedia not always being accurate? We don't want any Firefox user to ever find info on Sumo that is incorrect. If individual contributors show that they can be trusted making responsible edits to Sumo content, they will be given the privilege of making edits without review.

What category setup would best fit that end-goal?

Comment 5

[Nelson Ko [:nkoth]]

I think so long as there is Staging Area vs. KB at present is enough to achieve this. The additional "Sandbox/Internal Testing Area" is useful just for stuff that is pure testing - not meant to be reviewed/approved.

Re naming convention: This is what I suggest:

1) New articles are created as is (since the name is unique). So an article "Plugin Manager" which is in the staging area is a new article. When it is approved, the category just needs to be changed - easy.

2) Staging area articles (branch of live articles) are prefixed with asterisk. E.g. "*Plugin Manager" is the staging area branch of "Plugin Manager".

Also, I can customize a simple "copy to staging area" option under actions for contributors. This "copy to staging area" option will display as "edit staging area version" if the staging area version has already been created. Staging area versions are simply identified by *Pagename as per the naming convention above.

How does this sound?

Comment 6

[Chris Ilias [:cilias]]

New contributors are going to click on the edit button on the live article. Anything we can do to address that?

Comment 7

[Nelson Ko [:nkoth]]

How about locking the live article?

Comment 8

[Chris Ilias [:cilias]]

New contributors are still not going to know how to apply the edits they want to make.

Comment 9

[Nelson Ko [:nkoth]]

OK. I have made the following changes. Please check it out.

1) When a page is locked, there will be a "edit staging copy" in the Actions box.

2) When a contributor clicks on this "edit staging copy", he will edit a page by the name of *Pagename of original page (i.e. prefixed with asterisk).

3) If the page is already prefixed with asterisk, there will be no option to "edit staging copy" in the Actions box. Instead, there will be an option to "view published copy" which will bring the user back to view the knowledge base copy.

4) Only users in the Approvers group and System Admins group have "Knowledge Base" in the choice of categories to choose from when editing (except when article is already in Knowledge Base so as to avoid breaking existing categorization). (admin tip) The permission I have used to control this ability is tiki_p_approve_submission.

Comment 10

[Nelson Ko [:nkoth]]

Actually, I kind of find the page name being *Pagename not particularly intuitive for new contributors. I can think of 2 options:

1. change it to *copy* Pagename, or something like that.

2. simply not show the '*' (but perhaps somewhere there could be an indication that this is a staging copy, beyond just having "view published copy" in the actions box?)

Comment 11

[Chris Ilias [:cilias]]

If I log in as Chris_Ilias_user, I cannot create an article in the KB, but I can still edit an article in the KB category. That doesn't make sense to me. Registered users, not in the approvers group should not be able to make live changes, to articles in the KB category.

Comment 12

[Nelson Ko [:nkoth]]

If you lock the page now, you will achieve this, but with the side effect that only System Admins, and the person who locked the article can unlock it.

Right now, to resolve this side effect, the Approvers could be given tiki_p_admin_wiki privileges, but this may be too powerful (e.g. they can totally remove wiki history and pages).

In the next week, I will separate out the "unlock all locked pages" ability from the "too powerful" tiki_p_admin_wiki perm, using a new perm "tiki_p_override_locks".

Comment 13

[Michael Morgan [:morgamic]]

Is this fixed?  What is left for this bug to be resolved?

Comment 14

[Chris Ilias [:cilias]]

Mike: No, it's not fixed yet.

Nelson: I just put Chris_Ilias_user in the approvers group; and when I logged in as Chris_Ilias_user, I could not edit a locked article. I also don't like the idea of locking all live articles.

Comment 15

[Nelson Ko [:nkoth]]

There will be a more elegant solution without this locking business after I complete the upgrade.

Comment 16

[Chris Ilias [:cilias]]

The upgrade seems to have fixed this. We still need to remove the Admin category from the editor page; but that's a separate bug.