Talk:Draft namespace

Relationship between draft and main namespaces
I would like to comment on some ideas about how content in the main and draft namespaces can be related. In particular I though on how the following processes be supported:


 * Create a page (in the main namespace) for which a draft exists. Users trying to create an article on a topic, should be aware that a draft already exists for this topic. They should be encouraged to try to improve/publish the draft instead of starting from scratch. If the user creates the page in the regular way (not publishing the draft), the users that have worked n the draft should be informed of such event.
 * Create a draft for an existing page. If a page already exists in the min namespace, does it make sense to allow the creation of a draft for it? Draft creation can be disabled (or at least discouraged) for pages that already exist.
 * Page deletion. Moving to a draft state instead of deleting a new article could reduce the friction in the process of creating a new article. The user should be aware of the fact that the article have been moved to a draft state and indications on how to improve it.

Any other thoughts on this?

Pginer (talk) 15:04, 29 November 2013 (UTC)
 * The Page deletion idea has merit in my opinion. I've not thought about the others in any detail, but others have. Please see Article Creation Workflow/Design that was worked on a few years ago. 64.40.54.203 06:52, 30 November 2013 (UTC)

Category notes
This is more complicated than I expected after initial investigation. The queries for the category pages are done in CategoryViewer.php. I don't see a straightforward place to hook in to add a filter on namespace. CategoryTree works by subclassing the whole viewer and using a ArticleFromTitle hook to ensure the new viewer is used. We could do that if necessary. We would probably want to subclass CategoryTreeCategoryViewer; at least CategoryTree is enabled throughout the production cluster, so we can just make it a hard dependency. Still, some kind of change to CategoryViewer would probably be necessary. This might be breaking out the logic for building extraConds to a protected method so the subclass can override it. Alternatively, we could add an appropriate hook.

Then there's the other end, where the articles are actually added to the categorylinks table. I think this in LinksUpdate.php. We can use (tested) LinksUpdateConstructed to delete the categories before they ever hit categorylinks. That would mean there could be no toggle (show/hide drafts), though we could exempt certain categories (e.g. draft tracking categories) with some more code at save-time.

There are also some tricky things we could do like changing the sort order, but that's probably a lot of complexity for low return. Superm401 - Talk 01:20, 6 December 2013 (UTC)