Last modified: 2014-04-11 08:27:43 UTC
We need a namespace to support creating/editing new content pages in draft mode. The most basic requirements for this namespace are: * Pages would be prepended with Draft, e.g. "Draft:Title" until they moved in to main content namespace or deleted. * All pages in the Draft namespace would be NOINDEXED to avoid having them confused with regular content pages by search engines (and thus also by readers). This request originally comes from English Wikipedia, but is definitely relevant to Wikipedia in all languages. It's also potentially useful to other Wikimedia projects or MediaWiki instances, though requirements like NOINDEXing may be less relevant.
Moving to site requests, adding a new namespace doesn't require an extension.
$wgNamespaceRobotPolicies can be used to set NOINDEX for the entire namespace.
(In reply to comment #1) > Moving to site requests, adding a new namespace doesn't require an extension. Hey. We don't intend to just add a new namespace straight away without more definition of how it will work, and the subsequent requirements. We also don't intend to limit it to enwiki, but rather do something that can be more widely applicable across languages. I added it to extension requests because in addition to just the bare requirements of a new namespace, we intend to build and test related enhancements like custom landing pages and reviewing tools for drafts. Those will almost certainly require an extension. There's more discussion on the Talk page of https://www.mediawiki.org/wiki/Wikipedia_article_creation Please do not fulfill this as a site request without giving us room to define the requirements more, and ideally, run some A/B tests on landing pages etc.
(In reply to comment #3) > Hey. > > We don't intend to just add a new namespace straight away without more > definition of how it will work, and the subsequent requirements. We also > don't > intend to limit it to enwiki, but rather do something that can be more widely > applicable across languages. > > I added it to extension requests because in addition to just the bare > requirements of a new namespace, we intend to build and test related > enhancements like custom landing pages and reviewing tools for drafts. Those > will almost certainly require an extension. There's more discussion on the > Talk > page of https://www.mediawiki.org/wiki/Wikipedia_article_creation > > Please do not fulfill this as a site request without giving us room to define > the requirements more, and ideally, run some A/B tests on landing pages etc. Would have been nice to mention this in the initial bug report.
(In reply to comment #0) > This request originally comes from English Wikipedia, but is definitely > relevant to Wikipedia in all languages. It's also potentially useful to other > Wikimedia projects or MediaWiki instances, though requirements like > NOINDEXing may be less relevant. I beg to differ; this is not relevant for other Wikipedia projects, because none of them--except ckb.wikipedia, fa.wikipedia and id.wikipedia--forbid non-registered users from creating pages (via '*' => array( 'createpage' => false ),). That said, creating a namespace for en.WP should be easy enough.
(In reply to comment #5) > (In reply to comment #0) > > > This request originally comes from English Wikipedia, but is definitely > > relevant to Wikipedia in all languages. It's also potentially useful to other > > Wikimedia projects or MediaWiki instances, though requirements like > > NOINDEXing may be less relevant. > > I beg to differ; this is not relevant for other Wikipedia projects, because > none of them--except ckb.wikipedia, fa.wikipedia and id.wikipedia--forbid > non-registered users from creating pages (via '*' => array( 'createpage' => > false ),). > > That said, creating a namespace for en.WP should be easy enough. If you check out the related English Wikipedia RFC, you can see that folks do not mean for it solely to facilitate page creation by anons. It's intent is as a tool for everyone, especially new registered users. If our problem was solely creating drafts by IPs, we definitely wouldn't be building something for anywhere by enwiki.
(In reply to comment #4) > (In reply to comment #3) > > > Hey. > > > > We don't intend to just add a new namespace straight away without more > > definition of how it will work, and the subsequent requirements. We also > > don't > > intend to limit it to enwiki, but rather do something that can be more widely > > applicable across languages. > > > > I added it to extension requests because in addition to just the bare > > requirements of a new namespace, we intend to build and test related > > enhancements like custom landing pages and reviewing tools for drafts. Those > > will almost certainly require an extension. There's more discussion on the > > Talk > > page of https://www.mediawiki.org/wiki/Wikipedia_article_creation > > > > Please do not fulfill this as a site request without giving us room to define > > the requirements more, and ideally, run some A/B tests on landing pages etc. > > Would have been nice to mention this in the initial bug report. Sorry for the confusion.
I don't understand. If this is supposed to be an extension also for projects other than the English Wikipedia, where can the name be discussed? Anticipating my opinion: not only "Drafts" is taken as a name, but at least in my understanding of the word "draft" all wiki pages (particularly Wikimedia projects' articles) are eternal drafts, work in progress. So, if this is about a process to propose/develop new pages for the content namespaces of a wiki, I strongly suggest using another name: there are several established ones among which to pick, for instance "Article [for] creation" (en.wiki), "Sandbox" (many wikis), "Incubator" (ru.wiki).
(In reply to comment #8) > I don't understand. If this is supposed to be an extension also for projects > other than the English Wikipedia, where can the name be discussed? > > Anticipating my opinion: not only "Drafts" is taken as a name, but at least > in my understanding of the word "draft" all wiki pages (particularly Wikimedia > projects' articles) are eternal drafts, work in progress. So, if this is > about a process to propose/develop new pages for the content namespaces of a > wiki, I strongly suggest using another name: there are several established ones > among which to pick, for instance "Article [for] creation" (en.wiki), "Sandbox" > (many wikis), "Incubator" (ru.wiki). The name can be overridden locally if needed, through $wgExtraNamespaces (before it's enabled on a wiki, to avoid switching complications). I agree "Wikipedia is not finished", but I really don't often see people refer to regular articles as drafts, so I think "Draft" is pretty straightforward. That said, "Sandbox" is another reasonable candidate.
(In reply to comment #9) > I agree "Wikipedia is not finished", but I really don't often see people > refer > to regular articles as drafts, so I think "Draft" is pretty straightforward. However there is no bright line, so the chances for the name to be problematic in other languages are bigger. > > That said, "Sandbox" is another reasonable candidate. Ok, let's make the bug summary a bit more to the point then.
(In reply to comment #9) > > The name can be overridden locally if needed, through $wgExtraNamespaces > (before it's enabled on a wiki, to avoid switching complications). > If a local community wants a different term than "Draft" for the namespace title we can customize it. In English, draft is our preferred default name for now.
This seems related to bug 27311 and bug 41363.
(In reply to comment #12) > This seems related to bug 27311 and bug 41363. Yep. Added as See alsos. Thank you!
I personally am not very fond of the "Draft:" name for this namespace. Technically, everything on wiki is a "draft" and this doesn't seem to show how it is different from any other article. I would prefer to see such a namespace named something more like "Concept:" which indicates that these particular drafts are not ready for full inclusion in the wiki yet and are still in the "idea" and "development" stage. Perhaps I'm being to nit-picky and specific and the majority of the rest of everyone else really doesn't care what it is named, but I wanted to make sure I got my opinion in (since everyone has one)...
Steve Walling said: "I added it to extension requests because in addition to just the bare requirements of a new namespace, we intend to build and test related enhancements like custom landing pages and reviewing tools for drafts." This wasn't part of the proposal that gained consensus. The proposal was for a new namespace called Draft:, and that the current AFC documentation and templates would simply be changed to direct users to it. I'm not entirely sure what Steve intends to add that would require an extension, but whatever it is, and if there winds up being consensus for it, it can be applied after the new namespace is in place just as well. There was also nothing in the proposal about other languages or projects, but if they would like the added namespace as well, they can request that it be added as well, and whatever this extension might be can also be added to those later. Let's please implement the proposal as written, and as agreed upon by the enwiki community, so that the volunteers at AFC and the template/script/bot coders can get started.
(In reply to comment #15) > Steve Walling said: "I added it to extension requests because in addition to > just the bare requirements of a new namespace, we intend to build and test > related > enhancements like custom landing pages and reviewing tools for drafts." > > This wasn't part of the proposal that gained consensus. The proposal was for > a > new namespace called Draft:, and that the current AFC documentation and > templates would simply be changed to direct users to it. > > I'm not entirely sure what Steve intends to add that would require an > extension, but whatever it is, and if there winds up being consensus for it, > it > can be applied after the new namespace is in place just as well. There was > also > nothing in the proposal about other languages or projects, but if they would > like the added namespace as well, they can request that it be added as well, > and whatever this extension might be can also be added to those later. > > Let's please implement the proposal as written, and as agreed upon by the > enwiki community, so that the volunteers at AFC and the template/script/bot > coders can get started. The proposal as written is not even close to describing all necessary details of how a Draft namespace would operate. All it does is show English Wikipedia supports a Draft namespace. For instance, it doesn't outline: * How publishing to mainspace would work. Is it the regular page move function which is hidden from view, or should we augment the editing toolbar to include publish actions? * What is the entry point for draft creation? Do we still send all new users to AFC via Search? * Do we include starting a draft as a secondary option when searching? * Do we suggest creating a draft as an option when visiting a red link? Do we do that for all users or just new ones? People said we should consider strongly suggesting drafts to new editors. So do we send users on a red link to create Drafts first, if they new? * Do we let new users publish to mainspace at any point they like? Or do we strongly suggest secondary review like AFC, and prevent page moves by non-autoconfirmed users in the Draft namespace? These fundamental questions and others need to be answered. As I said on the RFC, the best way to do this is to test things. In any case, we're not ready to just whip out a new namespace that works exactly like the main namespace but is titled Draft. That's not enough. Otherwise the proposal will be worthless, because new users and experienced ones alike will have a hard time finding the ability create drafts and publish them.
(In reply to comment #16) > The proposal as written is not even close to describing all necessary details > of how a Draft namespace would operate. All it does is show English Wikipedia > supports a Draft namespace. > > For instance, it doesn't outline: > > * How publishing to mainspace would work. Is it the regular page move > function > which is hidden from view, or should we augment the editing toolbar to > include > publish actions? > * What is the entry point for draft creation? Do we still send all new users > to > AFC via Search? > * Do we include starting a draft as a secondary option when searching? > * Do we suggest creating a draft as an option when visiting a red link? Do we > do that for all users or just new ones? People said we should consider > strongly > suggesting drafts to new editors. So do we send users on a red link to create > Drafts first, if they new? > * Do we let new users publish to mainspace at any point they like? Or do we > strongly suggest secondary review like AFC, and prevent page moves by > non-autoconfirmed users in the Draft namespace? > > These fundamental questions and others need to be answered. As I said on the > RFC, the best way to do this is to test things. In any case, we're not ready > to > just whip out a new namespace that works exactly like the main namespace but > is > titled Draft. That's not enough. Otherwise the proposal will be worthless, > because new users and experienced ones alike will have a hard time finding > the > ability create drafts and publish them. The proposal states that new article proposals would still go through AFC. There is no more reason to discuss further changes to search etc. than there was prior to this proposal. We didn't add AFC links to search before, and we don't need to now as a block to implementing the Draft namespace. These questions are not fundamental to the creation of a draft namespace, as nothing would be changing in the AFC process besides the location of drafts. They do not have to block its creation. They are all possible enhancements to AFC that can be added on later.
(In reply to comment #17) > These questions are not fundamental to the creation of a draft namespace, as > nothing would be changing in the AFC process besides the location of drafts. > They do not have to block its creation. They are all possible enhancements to > AFC that can be added on later. I'd recommend filing a separate bug report for the creation of a "Draft" namespace on the English Wikipedia. There are instructions here: [[m:Requesting a wiki configuration change]].
Might I be so bold as to suggest such a feature for core, rather than an extension. The see alsos suggest that. We would help tons and tons more people that way.
(In reply to comment #18) > (In reply to comment #17) > > These questions are not fundamental to the creation of a draft namespace, as > > nothing would be changing in the AFC process besides the location of drafts. > > They do not have to block its creation. They are all possible enhancements to > > AFC that can be added on later. > > I'd recommend filing a separate bug report for the creation of a "Draft" > namespace on the English Wikipedia. There are instructions here: > [[m:Requesting > a wiki configuration change]]. I would do that immediately if this bug didn't concern the same proposal and contain the same Draft namespace creation (along with these other monkey wrenches). It might simply be marked as a duplicate. I rather hope we can correct this bug request so that it becomes what it was supposed to be.
(In reply to comment #17) > > The proposal states that new article proposals would still go through AFC. > There is no more reason to discuss further changes to search etc. than there > was prior to this proposal. We didn't add AFC links to search before, and we > don't need to now as a block to implementing the Draft namespace. > > These questions are not fundamental to the creation of a draft namespace, as > nothing would be changing in the AFC process besides the location of drafts. > They do not have to block its creation. They are all possible enhancements to > AFC that can be added on later. I don't think you're correct here. The closure says that AFC doesn't need to change, not that we should continue to make all new article proposals continue to go through it. There's not actually a consensus that new articles must be proposed through AFC. Also, search *does* link to AFC on English Wikipedia, just log out and search for something. Part of the reason the Draft namespace was asked for was because the homegrown scripts, templates, and bots at AFC are not robust enough to handle the large volume of page creations on English Wikipedia. Let's not make the same mistake twice, if we want really avoid creating a new backlog like the 40,000+ abandoned drafts that still need to be cleaned up. Now that's clear there's support, let's work on defining what the absolute minimum viable requirements are for the new namespace. Let's not be hasty in adding a namespace we want to be successful and persist for a long time. There's no deadline.
(In reply to comment #19) > Might I be so bold as to suggest such a feature for core, rather than an > extension. The see alsos suggest that. > > We would help tons and tons more people that way. Matt F. and I have discussed this a little bit at https://www.mediawiki.org/wiki/Talk:Wikipedia_article_creation We should keep detailed discussion there, but we're leaning toward an extension, because not all wikis are going to want a Draft namespace right away, necessarily. We probably want to be able to turn it on selectively at first, even if we're aiming for something generally useful beyond English Wikipedia. Migrating to Core in the future when it's more road-tested seems wise to me.
(In reply to comment #22) > We should keep detailed discussion there, but we're leaning toward an > extension, because not all wikis are going to want a Draft namespace right > away, necessarily. Make it configurable. > We probably want to be able to turn it on selectively at > first, even if we're aiming for something generally useful beyond English > Wikipedia. Again, make it configurable (off by default, at first :)) > Migrating to Core in the future when it's more road-tested seems > wise to me. Moving to core is always harder than just developing in core to begin with. Case in point: Vector extension.
(In reply to comment #18) > I'd recommend filing a separate bug report for the creation of a "Draft" > namespace on the English Wikipedia. Filed as bug 57569.
(In reply to comment #21) > (In reply to comment #17) > > I don't think you're correct here. The closure says that AFC doesn't need to > change, not that we should continue to make all new article proposals > continue > to go through it. There's not actually a consensus that new articles must be > proposed through AFC. Also, search *does* link to AFC on English Wikipedia, > just log out and search for something. > > Part of the reason the Draft namespace was asked for was because the > homegrown > scripts, templates, and bots at AFC are not robust enough to handle the large > volume of page creations on English Wikipedia. Let's not make the same > mistake > twice, if we want really avoid creating a new backlog like the 40,000+ > abandoned drafts that still need to be cleaned up. > > Now that's clear there's support, let's work on defining what the absolute > minimum viable requirements are for the new namespace. Let's not be hasty in > adding a namespace we want to be successful and persist for a long time. > There's no deadline. The proposal to create the Draft namespace was partially to make things easier on the homegrown solutions. It wasn't to render them unneeded through software changes. The closure states: "... no challenge was made to the proviso that AfC would continue as it currently does. This community discussion does not change the AfC process—any such decisions should be ones that the AfC WikiProject should make through further consensus-based discussion if they deem it to be necessary." Steven said: "Now that's clear there's support, let's work on defining what the absolute minimum viable requirements are for the new namespace." The requirement was met. It was proposed and gained consensus. I understand that you want to create further requirements now because you personally think there should be some -- but that's not how this is supposed to work. Your suggestions may have merit, but can be discussed and implemented later. Implementing the draft space now does no harm to them. (In reply to comment #24) > (In reply to comment #18) > > I'd recommend filing a separate bug report for the creation of a "Draft" > > namespace on the English Wikipedia. > > Filed as bug 57569. Thank you, MZMcBride.
(In reply to comment #23) > (In reply to comment #22) > > We should keep detailed discussion there, but we're leaning toward an > > extension, because not all wikis are going to want a Draft namespace right > > away, necessarily. > > Make it configurable. > > > We probably want to be able to turn it on selectively at > > first, even if we're aiming for something generally useful beyond English > > Wikipedia. > > Again, make it configurable (off by default, at first :)) > > > Migrating to Core in the future when it's more road-tested seems > > wise to me. > > Moving to core is always harder than just developing in core to begin with. > Case in point: Vector extension. My experience developing for account creation and login says otherwise. Quite simple and not at all outlandish design changes there took us way too long to get merged. Developing in core has a (necessarily) high barrier for quality and an implied requirement that what you intend to commit is more or less intended to be permanent. A draft namespace is a new idea that's somewhat experimental, and we intend to approach with an eye toward testing out what is going to work for authors or not.
(In reply to comment #26) > Developing in core has a (necessarily) high barrier for quality Yes, I view this as a good thing. I hope this means you're not planning to cut corners and hide bad code in an extension ;-) > and an > implied > requirement that what you intend to commit is more or less intended to be > permanent. A draft namespace is a new idea that's somewhat experimental, and > we > intend to approach with an eye toward testing out what is going to work for > authors or not. Not true. We've done plenty of experimental things in core before. The trick is hiding them behind a feature flag so if we decide it's not such a great idea, we can nuke it later (case in point: HTMLDiff). I see how people may find developing core code daunting, but hiding in extensions isn't the way to make MediaWiki better, and I have insanely serious doubts about us ever moving extensions to core in a timely manner :)
(In reply to comment #19) > Might I be so bold as to suggest such a feature for core, rather than an > extension. The see alsos suggest that. It's definitely possible that this will end up in core at some point. > We should keep detailed discussion there, but we're leaning toward an > extension, because not all wikis are going to want a Draft namespace right > away, necessarily. However, Chad is right that that doesn't necessarily require an extension. The namespace part can be done in wmf-config (that doesn't mean we necessarily will), and core variables can be gated. (In reply to comment #23) > Moving to core is always harder than just developing in core to begin with. > Case in point: Vector extension. You can look at that both ways. On the plus side, it enabled quicker experimentation (both in the code sense and the analytics sense). It successfully resulted in some good functionality that was moved to core. Other stuff was done in core in a significantly different way, after learning lessons from the extension implementation. I think it also kept some rejected functionality out of core. On the downside, there was definitely Vector functionality that should have been moved to core sooner.
(In reply to comment #25) > The proposal to create the Draft namespace was partially to make things > easier on the homegrown solutions. It wasn't to render them unneeded through > software changes. It's true the closure said there was no immediate change to AFC. However, I don't agree that maintaining lots of bot- and userscript-based Draft processes is a key goal. The key goal is to "simplify the process of submitting draft articles" (as the closure put it). Steven was clear in the RFC comments: "I think we should take an experimental approach to this, objectively testing out how a new Drafts namespace should work." and "I want to test asking new article creators if they want to start a draft first before publishing to mainspace." There is a lot of MW software development that is not specifically requested by an RFC (including the original wiki software). It's always going to be a back and forth.
Changing the title to reflect that we're going to look closer at where to put stuff, and a core feature flag is one possibility. It might allow easier and tighter integration/replacement of certain features (search pages, redlinks, etc), even though hooks remain an option.
This bug got hopelessly confusing with all these discussions about closures and whatnot, which should continue at bug 57569. If the outcome of this discussion is to work on this in core, this bug should be duplicated to bug 27311, which has clearer requirements, and other stuff added to its dependencies (as in, the "/managing" part of the summary, which was never asked so far; that can be blocked on bug 27311).
The first phase of this will be just the namespace. The launch requirements are being hashed out at https://www.mediawiki.org/wiki/Draft_namespace . If you see any missing questions that should be resolved pre-launch, add them.
(In reply to comment #32) > The first phase of this will be just the namespace. The launch requirements > are being hashed out at https://www.mediawiki.org/wiki/Draft_namespace . If > you see any missing questions that should be resolved pre-launch, add them. I added a couple of namespaces in the past and I wasn't held to this standard, which seems a bit much. (It's fine as a list of desiderata, but not as a list of merge blockers.) If MZMcBride (as patch submitter) is not persuaded that waiting is sensible, we should just merge the patch and get on with it. The risk of having to do extra work to migrate content is dwarfed by the inevitability of this discussion metastasizing into a contest of legitimacy and power -- a process that is already well underway, it seems. If it drags on much longer, it will annihilate any possibility of fruitful collaboration in this sphere. My vote is therefore to merge (with noted reluctance, if you like) and to move on.
(In reply to comment #33) > (In reply to comment #32) > > The first phase of this will be just the namespace. The launch requirements > > are being hashed out at https://www.mediawiki.org/wiki/Draft_namespace . If > > you see any missing questions that should be resolved pre-launch, add them. > > I added a couple of namespaces in the past and I wasn't held to this > standard, > which seems a bit much. (It's fine as a list of desiderata, but not as a list > of merge blockers.) If MZMcBride (as patch submitter) is not persuaded that > waiting is sensible, we should just merge the patch and get on with it. The > risk of having to do extra work to migrate content is dwarfed by the > inevitability of this discussion metastasizing into a contest of legitimacy > and > power -- a process that is already well underway, it seems. If it drags on > much > longer, it will annihilate any possibility of fruitful collaboration in this > sphere. My vote is therefore to merge (with noted reluctance, if you like) > and > to move on. I'm okay with delaying some of the questions I brought up for the future, but I do think the requirements are necessary. To be fair Ori, namespaces I think you've added are things like Schema. These were not requested by the community, and we had complete control over what we thought was minimally necessary. They also didn't have the kind of far-reaching impact that a Draft namespace on our largest project does. I'm not saying we need to wait months or something, but I am saying we should make sure the absolute basics are agreed on and tested.
(In reply to comment #34) > I'm okay with delaying some of the questions I brought up for the future, > but I > do think the requirements are necessary. > > To be fair Ori, namespaces I think you've added are things like Schema. These > were not requested by the community, and we had complete control over what we > thought was minimally necessary. They also didn't have the kind of > far-reaching > impact that a Draft namespace on our largest project does. I'm not saying we > need to wait months or something, but I am saying we should make sure the > absolute basics are agreed on and tested. Yes, we could wait for Steve to completely squirm out of his original position with corporate speak in order to preserve his pride, but I think it would be more time-efficient to simply move ahead now. I'm just saying this for the record. If anyone has some non-vague reason to say any of this is still necessary let's hear it clearly and specifically.
Anyone else remember the Table namespace? What have been the long term lasting implications of that little experiment? You know the best part about namespaces? We can totally undo them later if we find out it's a bad idea :)
(In reply to comment #33) > I added a couple of namespaces in the past and I wasn't held to this > standard, which seems a bit much. Those weren't namespaces on English Wikipedia with custom hooks and changes to robot policy. Even though Meta is a user-facing project, Schema is not intended to be used by most Meta users. Anyway, as far as I can tell, the requirements are done (categories should not be in the launch requirements). Please bear in mind part of the delay has been over Thanksgiving. My goal is to get this out very soon, with testing on Beta (which should not cause a delay). (In reply to comment #35) > Yes, we could wait for Steve to completely squirm out of his original > position with corporate speak in order to preserve his pride, but I think it > would be more time-efficient to simply move ahead now. Please stop trying to make this personal.
> (In reply to comment #35) > > Yes, we could wait for Steve to completely squirm out of his original > > position with corporate speak in order to preserve his pride, but I think it > > would be more time-efficient to simply move ahead now. > > Please stop trying to make this personal. It wasn't my intention to provoke a personal altercation, even if some of my comments could be interpreted that way. I'm merely saying out loud what many of us see but are unwilling to volunteer (probably for good reason, but I'm fine being it, having no ties or reputation to preserve). Individuals should be pointed out when they act in a way that contributes to the systemic problem that the community overwhelmingly feels is present and the Wikimedia Foundation denies. It's important that someone be willing to do that, or else there's little chance it'll ever change. (In reply to comment #37) > (In reply to comment #33) > > I added a couple of namespaces in the past and I wasn't held to this > > standard, which seems a bit much. > > Those weren't namespaces on English Wikipedia with custom hooks and changes > to > robot policy. Even though Meta is a user-facing project, Schema is not > intended to be used by most Meta users. > > Anyway, as far as I can tell, the requirements are done (categories should > not > be in the launch requirements). > > Please bear in mind part of the delay has been over Thanksgiving. My goal is > to get this out very soon, with testing on Beta (which should not cause a > delay). Thank you. So long as delays aren't caused by various unproposed and inappropriate extras, I'm personally fine with people taking their time. I was actually going to give the understandable Thanksgiving lull another day or two before asking questions again, but was contacted yesterday by another user, and figured it was as good a time as any. It's good to know the requirements are now finished and the configuration change that effectively creates the namespace can now be implemented. Please let us know if any further causes for delay materialize. Otherwise I'm excited to see this new namespace.
FYI for all interested, we're testing the current namespace patch on Labs now. Try it out at: http://en.wikipedia.beta.wmflabs.org Requirements: https://www.mediawiki.org/wiki/Draft_namespace
We probably shouldn't have used 110 as the namespace number. It conflicts with other namespaces in use on other WMF wikis.
(In reply to comment #40) > We probably shouldn't have used 110 as the namespace number. It conflicts > with other namespaces in use on other WMF wikis. Conflicts how?
(In reply to comment #41) > (In reply to comment #40) > > We probably shouldn't have used 110 as the namespace number. It conflicts > > with other namespaces in use on other WMF wikis. > > Conflicts how? I'm assuming he means you'd generally want namespace numbers to be uniform across wikis. It would be confusing if 110 referred to draft space on enwiki but something else on another wiki. A number that's currently not used on any WMF wiki should probably be used for this. It would be especially useful just in case other wikis wants to implement their own draft namespace in the future, so they all have the same number.
(In reply to comment #42) > (In reply to comment #41) > > (In reply to comment #40) > > > We probably shouldn't have used 110 as the namespace number. It conflicts > > > with other namespaces in use on other WMF wikis. > > > > Conflicts how? > > I'm assuming he means you'd generally want namespace numbers to be uniform > across wikis. It would be confusing if 110 referred to draft space on enwiki > but something else on another wiki. A number that's currently not used on any > WMF wiki should probably be used for this. It would be especially useful just > in case other wikis wants to implement their own draft namespace in the > future, > so they all have the same number. Yeah that. I know they don't have to be unique across all wikis, just unique to the wiki in question, but it makes life easier for everyone when it is :)
(In reply to comment #40) > We probably shouldn't have used 110 as the namespace number. It conflicts > with other namespaces in use on other WMF wikis. It's on Beta Labs, but not merged yet to production, so we can do that. I was just assuming the goal was "no numbering gap on individual wikis". So it looks like the lowest unused throughout the cluster is 118. Is 118/119 alright?
(In reply to comment #44) > (In reply to comment #40) > > We probably shouldn't have used 110 as the namespace number. It conflicts > > with other namespaces in use on other WMF wikis. > > It's on Beta Labs, but not merged yet to production, so we can do that. I > was > just assuming the goal was "no numbering gap on individual wikis". > > So it looks like the lowest unused throughout the cluster is 118. > > Is 118/119 alright? If it's not used anywhere else, it sounds like a fine choice to me :)
