Wikimedia Bugzilla is closed!

Like I said on bug 57315, there are still too many unanswered questions about this namespace to roll it out in a hasty way. Please be patient. It's only been a week since the RFC on enwiki was closed.

(In reply to comment #1)
> Like I said on bug 57315, there are still too many unanswered questions about
> this namespace to roll it out in a hasty way.

Does anyone else share your view?

(In reply to comment #2)
> (In reply to comment #1)
> > Like I said on bug 57315, there are still too many unanswered questions about
> > this namespace to roll it out in a hasty way.
> 
> Does anyone else share your view?

This is not about consensus. We don't know basic things about how the namespace would work. We still need to specify things like:

* who is allowed to create drafts. (e.g. Are anonymous users allowed to do so? I assume so but the proposal summary and closure don't specify.)
* how to publish drafts
* who is allowed to publish drafts
* how do we tell users they can create/publish drafts, on search, redlinks, and other places
* do we want to let people make drafts of pages that already exist?

There are numerous other smaller details to work out as well.

As I stated at the other bug, these are not questions that need to block creation of the namespace. It rather seems apparent that you saw this proposal as something other than it was -- a more substantial change to AFC that you had already envisioned prior -- but it wasn't, and the closure states that pretty clearly. 

Anyone is allowed to create drafts because anyone was allowed to before. This is just a change to their location.

Publishing drafts will continue to merely require a move to mainspace, because that's all that was required before. 

We don't need to tell anyone anything other than through altered documentation at AFC, because nothing other than that will be changing. 

Phrasing these added proposals as questions doesn't make them requirements that apply to this proposal. They are merely possible additions that should be proposed and discussed separately. As concerns this proposal, we need only create a draft namespace.

(In reply to comment #4)
> As I stated at the other bug, these are not questions that need to block
> creation of the namespace. 

Deciding the basics of who can do what in a new namespace, and how, are things that block creating a new namespace. 

I really don't see why you're in such a huge hurry. This is quite a large new feature, so understanding the basics of how it will function in relation to regular page creation, the permissions involved, and so on seem quite obviously basic things we need to figure out before we deploy a major new namespace to English Wikipedia.

(In reply to comment #3)
> This is not about consensus. We don't know basic things about how the
> namespace would work.

I'm pretty sure we know how namespaces work. :-)

> We still need to specify things like:
> 
> * who is allowed to create drafts. (e.g. Are anonymous users allowed to do
> so?
> I assume so but the proposal summary and closure don't specify.)
> * how to publish drafts
> * who is allowed to publish drafts
> * how do we tell users they can create/publish drafts, on search, redlinks,
> and other places
> * do we want to let people make drafts of pages that already exist?

None of this is relevant to adding a new namespace and you know this.

If you want to improve the articles for creation process, great! I've filed several bugs in this area. :-)  No objections from me.

But the two ideas (adding a new namespace on the English Wikipedia and improving the articles for creation process) are not tied to each other in any meaningful way. We're talking about a two-line configuration change here.

> None of this is relevant to adding a new namespace and you know this.
> 
> If you want to improve the articles for creation process, great! I've filed
> several bugs in this area. :-)  No objections from me.
> 
> But the two ideas (adding a new namespace on the English Wikipedia and
> improving the articles for creation process) are not tied to each other in
> any
> meaningful way. We're talking about a two-line configuration change here.

I'm not talking about articles for creation at all. That's a community process, not a software feature that has direct overlap with a drafts namespace, with the exception of what we want to appear on search.

(In reply to comment #6)
> We're talking about a two-line configuration change here.

Probably a few more than two lines to create the namespace, the talk namespace, and set noindex. Maybe a half-dozen to a dozen lines? In any case, this seems fairly easy to implement to me.

(In reply to comment #7)
> I'm not talking about articles for creation at all. That's a community
> process,
> not a software feature that has direct overlap with a drafts namespace, with
> the exception of what we want to appear on search.

The accepted proposal we seek to implement here doesn't concern any software feature. If you want one, propose one separately. You've stated nothing that couldn't also be applied without a draft namespace, or after it's already created. They are separate suggestions, and they may be useful ones, but still have no bearing on the implementation of this namespace.

(In reply to comment #3)
> (In reply to comment #2)

> * who is allowed to create drafts. (e.g. Are anonymous users allowed to do
> so?
> I assume so but the proposal summary and closure don't specify.)

I've left Tom Morris (the RfC closer) a note asking him to clarify - [[Special:Permalink/583319065]].

That said, I don't think that question specifically blocks the creation of the namespace, a hook can be added to userCan later on to allow anon's to create pages in it.

(In reply to comment #6)
> > We still need to specify things like:
> > 
> > * who is allowed to create drafts. (e.g. Are anonymous users allowed to do
> > so?
> > I assume so but the proposal summary and closure don't specify.)
> > * how to publish drafts
> > * who is allowed to publish drafts
> > * how do we tell users they can create/publish drafts, on search, redlinks,
> > and other places
> > * do we want to let people make drafts of pages that already exist?
> 
> None of this is relevant to adding a new namespace and you know this.

All of those questions are relevant.  Some I certainly consider blockers.  For example, I am strongly inclined to determine an initial permission model before we deploy it (that's not the only one).  

It is irrelevant how many lines it takes to create a dumb namespace.  The questions are how it will function initially (which may include A/B testing multiple possibilities) and how it will relate to other features.

Change 97675 had a related patch set uploaded by MZMcBride:
Create "Draft" namespace on the English Wikipedia

https://gerrit.wikimedia.org/r/97675

I've not read the discussion but I have to say the closure is quite straightforward: «the heart of the proposal: a new namespace for Drafts [...] This community discussion does not change the AfC process». It obviously doesn't entail any extension, nor special user permissions for the namespace for that matter; those can come later if wanted.

(In reply to comment #2)
> (In reply to comment #1)
> > Like I said on bug 57315, there are still too many unanswered questions about
> > this namespace to roll it out in a hasty way.
> 
> Does anyone else share your view?

I fully share this view.  I've been toying with the idea of an extension here for some time.  There is this new namespace, there is the new userright that the community agreed upon, there are the common complaints that AfC templates and scripts don't do this or that (and can't be modified as the wiki stands to without creating an on-by-default gadget or adding code to MediaWiki:Common.js or possibly by creating a guided tour (which is a fairly new option that was introduced as I've been developing the extension)).  There are a LOT of factors that need to go into draft creation alone, not to mention I think (as I stated in bug 57315) that I think requested articles could be rolled into articles for creation and the whole process could be streamlined.  I'm constantly seeing stuff about editor retention and we need to do this and that and that is great, but what I have a problem with is the fact that our current fairly difficult to use system turns new editors away... Maybe stating the obvious, but if there are fewer new editors, then there is a much smaller pool to work from for retention.

(In reply to comment #4)
> As I stated at the other bug, these are not questions that need to block
> creation of the namespace. It rather seems apparent that you saw this
> proposal
> as something other than it was -- a more substantial change to AFC that you
> had
> already envisioned prior -- but it wasn't, and the closure states that pretty
> clearly. 
> 
> Anyone is allowed to create drafts because anyone was allowed to before. This
> is just a change to their location.
> 
> Publishing drafts will continue to merely require a move to mainspace,
> because
> that's all that was required before. 
> 
> We don't need to tell anyone anything other than through altered
> documentation
> at AFC, because nothing other than that will be changing. 
> 
> Phrasing these added proposals as questions doesn't make them requirements
> that
> apply to this proposal. They are merely possible additions that should be
> proposed and discussed separately. As concerns this proposal, we need only
> create a draft namespace.

Wait, IP editors aren't allow to create pages in this new draft: namespace?  They will still have to create in Draft_talk:?  At least that's what I'm reading here, exactly the same as before only people will use "Draft( talk):" instead of "Wikipedia( talk):Articles for creation/"?

(In reply to comment #14)
> I fully share this view.  I've been toying with the idea of an extension here
> for some time.  There is this new namespace, there is the new userright that
> the community agreed upon, there are the common complaints that AfC templates
> and scripts don't do this or that (and can't be modified as the wiki stands
> to
> without creating an on-by-default gadget or adding code to
> MediaWiki:Common.js
> or possibly by creating a guided tour (which is a fairly new option that was
> introduced as I've been developing the extension)).  There are a LOT of
> factors
> that need to go into draft creation alone, not to mention I think (as I
> stated
> in bug 57315) that I think requested articles could be rolled into articles
> for
> creation and the whole process could be streamlined.  I'm constantly seeing
> stuff about editor retention and we need to do this and that and that is
> great,
> but what I have a problem with is the fact that our current fairly difficult
> to
> use system turns new editors away... Maybe stating the obvious, but if there
> are fewer new editors, then there is a much smaller pool to work from for
> retention.

It's fine that you share Steven's view on that -- but the question was whether these things are a block to the Draft namespace implementation. An extension may be a good idea and I don't necessarily dispute that, but it wasn't part of this proposal and it regards changes that should be proposed separately. I might even support it, once it's clear what the proposed changes are (all I've seen spelled out so far are a new landing page and some sort of special permission changes, which are both still pretty vague).

(In reply to comment #14)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Like I said on bug 57315, there are still too many unanswered questions about
> > > this namespace to roll it out in a hasty way.
> > 
> > Does anyone else share your view?
> 
> I fully share this view.  

As do I. If a quick six-lines-of-code patch can work, then that is good. But if the long run requires a more comprehensive approach, then so it be. As far as I am concerned, the enwiki just needs the namespace in a reasonable amount of time. If those two requirements are met, I am fine with whichever proposal gets this done, as long as it does through whatever procedure it is normally expected to.

(In reply to comment #17)
> I am fine with whichever proposal
> gets
> this done, as long as it does through whatever procedure it is normally
> expected to.

Don't worry: the procedure is [[m:Requesting wiki configuration changes]]. It seems to be clear that there is consensus and we already have a patch, so now you only need the patch to be approved by a shell user, after it's verified that the code in question does what asked. Typically, that takes about a week or two of waiting; namespace creation is among the simplest and most routinary configuration changes happening in here, so I don't expect any problem.

(In reply to comment #4)
> As I stated at the other bug, these are not questions that need to block
> creation of the namespace.

There are no blockers; you can have the namespace. I do think it is being rushed, though.

I never quite understood how consensus is determined, so I may be getting this wrong, but reading over the RFC, I think a detect a shared conviction that a namespace by itself may not do the trick, and that some additional software support may be required. This much is entailed by the very thought of having a namespace in the first place, right?

Once the namespace exists, it will begin to be populated with content, and at that point the range of things you can practically do with it are severely limited. For example: MediaWiki provides an abstract framework for expressing an edit and review workflow called ContentHandler (<http://www.mediawiki.org/wiki/Manual:ContentHandler>). Taking the default content handler for articles (WikitextContentHandler) as a starting point and extending it so that it provides guided page creation and peer review interfaces seems like a potentially fruitful direction to take, and saddling it with the additional requirement of migrating existing content is a great way to ensure that it will never get done.

Steven Walling is well-positioned to enlist some developer time within the Foundation for this project. If he is asking for additional time to grok the requirements, the sensible and gracious thing to do is to grant it. If you can railroad the patch through today, you can do it two weeks from now, too.

I would recommend making the mapping of requirements collaborative by provisioning a MediaWiki instance in Labs, granting shell access to all interested parties, and using it as a staging area for hashing out how the namespace would work and how its purpose and function would be presented to editors.

(In reply to comment #16)
> I might even support it, once it's clear what the proposed changes are (all
> I've seen spelled out so far are a new landing page and some sort of special
> permission changes, which are both still pretty vague).

It's vague because that's one of the things we're still trying to figure out (before adding the namespace).

(In reply to comment #19)

I agree with most of what you wrote, though a lot of it is relevant to bug 57315 rather than this bug.

> Steven Walling is well-positioned to enlist some developer time within the
> Foundation for this project. If he is asking for additional time to grok the
> requirements, the sensible and gracious thing to do is to grant it. If you
> can railroad the patch through today, you can do it two weeks from now, too.

Requirements are still being gathered. As I understand it, no implementation ideas have been formally proposed yet, much less coded, and we're fast approaching the U.S. holiday season. I don't imagine we'll see any real work on bug 57315 before 2014. While it's possible to wait a few weeks (or months) to add this namespace, I don't see any benefit to doing so. The current system is so bad and so hackish that there's very little that could make it worse.

(In reply to comment #21)
> (In reply to comment #19)
> 
> I agree with most of what you wrote, though a lot of it is relevant to bug
> 57315 rather than this bug.
> 
> > Steven Walling is well-positioned to enlist some developer time within the
> > Foundation for this project. If he is asking for additional time to grok the
> > requirements, the sensible and gracious thing to do is to grant it. If you
> > can railroad the patch through today, you can do it two weeks from now, too.
> 
> Requirements are still being gathered. As I understand it, no implementation
> ideas have been formally proposed yet, much less coded, and we're fast
> approaching the U.S. holiday season. I don't imagine we'll see any real work
> on
> bug 57315 before 2014. While it's possible to wait a few weeks (or months) to
> add this namespace, I don't see any benefit to doing so. The current system
> is
> so bad and so hackish that there's very little that could make it worse.

Ori's point was partly that acting in a hasty manner and populating the namespace with content right, so that it's less flexible to essential changes in the near future, *will* make the situation worse. Or at the very least, replicate the current bad situation. Considering the patch you put up for review literally does replicate the current problem (IPs can't create actual drafts, just Talk pages), I am convinced by this argument. 

What I've asked for, and stated on-wiki, is that we need to at least do two things:

1). Actually write down the requirements for the namespace, and agree on them. I can commit to making this happen _far_ before 2014. Ideally in the current week.
2). Test the functionality on Labs or similar environment before deploying, with feedback from the community. People have responded positively to this idea, and we're using it with features like Flow as well. Giving people a chance to test drive the new namespace before dropping it on enwiki seems wise to me. 

Neither of these things necessarily require that all the potential features extending and improving the namespace be implemented. I do believe in releasing something that's "minimum viable product" quickly as is reasonable. But considering we have no agreement on what the minimum viable product is, we need to settle that first.

(In reply to comment #22)
> Ori's point was partly that acting in a hasty manner and populating the
> namespace with content right, so that it's less flexible to essential changes
> in the near future, *will* make the situation worse.

Worse than hypothetical future is not worse than the present, so it's still a gradual improvement. Populating a "drafts" namespace doesn't seem to pose any risk to me: it's completely normal to move pages in and out new namespaces (Wikipedia<->Draft in this case) and this namespace is supposed to be purged regularly anyway. If you're so worried about workload, you can run a move script yourself when it's time; the only real risk when creating namespace is forgetting to run namespaceDupes.php‎.

Key minimum requirements for launch are being hashed out at https://www.mediawiki.org/wiki/Draft_namespace .  Some are pretty definite already (e.g. NOINDEX), while others are not 100% certain yet.  We may also have omitted some questions, so if you think of any that need to be resolved before launch, add them.

I have a hard time understanding what is going on here? If this was any other wiki, we would note that their is community consensus, and implement the change.

The only thing slightly iffy thing here is to be able to let anons create pages in this namespace - that might require someone taking 10 seconds writing a hook (Or even better, someone fixing mediawiki so we have proper per-namespace permissions). However that can easily be done later. the robots thing is already a config option.

Furthermore, all these various "config" related changes are trivial to change after the fact if people discover they want something different.

New namespaces get created for other wikis all the time. This has traditionally been something that has entirely been up to the community to decide for themselves. I don't understand why enwiki gets treated so differently.

>Key minimum requirements for launch are being hashed out at
>https://www.mediawiki.org/wiki/Draft_namespace 

Kind of seems odd this is being written up on mediawiki.org, for something that is in essence a config change coming out of enwikipedia community. Its not like there are non-user facing technical hurtles to surmount. There's no new db schema being proposed or anything like that.

(In reply to comment #25)
> I have a hard time understanding what is going on here? If this was any other
> wiki, we would note that their is community consensus, and implement the
> change.
> 
> The only thing slightly iffy thing here is to be able to let anons create
> pages
> in this namespace - that might require someone taking 10 seconds writing a
> hook
> (Or even better, someone fixing mediawiki so we have proper per-namespace
> permissions). However that can easily be done later. the robots thing is
> already a config option.
> 
> Furthermore, all these various "config" related changes are trivial to change
> after the fact if people discover they want something different.
> 
> New namespaces get created for other wikis all the time. This has
> traditionally
> been something that has entirely been up to the community to decide for
> themselves. I don't understand why enwiki gets treated so differently.
> 
> >Key minimum requirements for launch are being hashed out at
> >https://www.mediawiki.org/wiki/Draft_namespace 
> 
> Kind of seems odd this is being written up on mediawiki.org, for something
> that
> is in essence a config change coming out of enwikipedia community. Its not
> like
> there are non-user facing technical hurtles to surmount. There's no new db
> schema being proposed or anything like that.

I suggest you check out the mediawiki.org page and the associated bug 57315. They both include some explanation, including the technical discussions involved about implementation, and about future plans.

> (In reply to comment #25)
> > I have a hard time understanding what is going on here? If this was any other
> > wiki, we would note that their is community consensus, and implement the
> > change.
> > 
> > The only thing slightly iffy thing here is to be able to let anons create
> > pages
> > in this namespace - that might require someone taking 10 seconds writing a
> > hook
> > (Or even better, someone fixing mediawiki so we have proper per-namespace
> > permissions). However that can easily be done later. the robots thing is
> > already a config option.
> > 
> > Furthermore, all these various "config" related changes are trivial to change
> > after the fact if people discover they want something different.
> > 
> > New namespaces get created for other wikis all the time. This has
> > traditionally
> > been something that has entirely been up to the community to decide for
> > themselves. I don't understand why enwiki gets treated so differently.
> > 
> > >Key minimum requirements for launch are being hashed out at
> > >https://www.mediawiki.org/wiki/Draft_namespace 
> > 
> > Kind of seems odd this is being written up on mediawiki.org, for something
> > that
> > is in essence a config change coming out of enwikipedia community. Its not
> > like
> > there are non-user facing technical hurtles to surmount. There's no new db
> > schema being proposed or anything like that.

Bawolff has a hard time understanding what most of us are having a hard time understanding. The piece you're missing, Bawolff, is that after this new namespace was proposed and passed as simply a new namespace, Steven Walling took it over by submitting the supposed bug for implementation (bug 57315), which was actually for something much more than a new namespace. 

While I'm sure he originally had the best of intentions, it was pointed out thereafter that his plan for implementation was markedly different from the accepted proposal that was supposed to have originated it. Rather than admit his error as a good Wikipedia administrator should, he's made every effort to outwardly cling to his original position like a good infallible corporate manager would: He attempted to pass off the bloat in his proposed implementation as "requirements" for the namespace, when they had actually been some new ideas he wanted to tinker with. The claim that these were "requirements" was again pointed out as erroneous, but he still insisted on making some list of requirements regardless, rather than simply letting it go. This is the show of complexity where none is actually necessary that you're seeing now and have astutely pointed out. 

And this is, in my mind, an example of the type of behavior that has brought the relationship between the WMF and the Wikipedia community to the sour state it is. And it felt good to get that out. 

Hope we can get some actual stuff done now.

Change 99600 had a related patch set uploaded by Mattflaschen:
Test under-review English Wikipedia draft namespace on Labs

https://gerrit.wikimedia.org/r/99600

Change 99600 merged by jenkins-bot:
Test under-review English Wikipedia draft namespace on Labs

https://gerrit.wikimedia.org/r/99600

(In reply to comment #8)
> (In reply to comment #6)
> > We're talking about a two-line configuration change here.
> 
> Probably a few more than two lines to create the namespace, the talk
> namespace,
> and set noindex. Maybe a half-dozen to a dozen lines? In any case, this seems
> fairly easy to implement to me.

We don't use easy keyword for shell bugs, as they're advertised not as "easy bug to write" but as "easy bugs for new contributors to discover the code". Shell bugs ask a knowledge of community consensus, and so they aren't suitable for newcomers.

(In reply to comment #30)
> We don't use easy keyword for shell bugs, as they're advertised not as "easy
> bug to write" but as "easy bugs for new contributors to discover the code".
> Shell bugs ask a knowledge of community consensus, and so they aren't
> suitable for newcomers.

I'm not sure this logic is sound. The "easy" keyword is associated with technical complexity. Couldn't we presume that the person adding the "easy" keyword is capable of making a full judgment of the bug, evaluating both the technical complexity and the social implications?

That is, committing a change for an "easy" shell ticket still allows new users to learn and experience Git and code review without them needing to be able to divine Wikimedia wiki consensus. On bugs where consensus, technical or otherwise, is unclear, there's a strong case for not marking the bug as "easy." I don't believe that's the case here or in many other cases of "shell" bugs.

I used to have very strong opinions on easy with shell bugs, but that was back in the svn days where you actually needed to be shell to do anything useful on these bugs. Now anyone can submit changes, so that argument is less compelling.

(In reply to comment #29)
> Change 99600 merged by jenkins-bot:
> Test under-review English Wikipedia draft namespace on Labs
> 
> https://gerrit.wikimedia.org/r/99600

FYI: we're testing the new namespace on Labs (http://en.wikipedia.beta.wmflabs.org). Please help give it a try.

(In reply to comment #33)
> FYI: we're testing the new namespace on Labs
> (http://en.wikipedia.beta.wmflabs.org). Please help give it a try.

Thank you for testing.

Please hold off on creating additional Drafts for now, until it is deployed (this is due to the namespace ID change mentioned at https://bugzilla.wikimedia.org/show_bug.cgi?id=57315#c44).

VisualEditor will be enabled in the namespace for opt-in users.  See https://www.mediawiki.org/wiki/Draft_namespace and https://gerrit.wikimedia.org/r/#/c/102311/ .

The VE stuff has now been included into the main change (https://gerrit.wikimedia.org/r/#/c/97675/).

Change 97675 merged by jenkins-bot:
Create "Draft" namespace on the English Wikipedia

https://gerrit.wikimedia.org/r/97675

This is deployed to English Wikipedia.

You can also resume testing on Beta.  The old drafts are at http://en.wikipedia.beta.wmflabs.org/wiki/Special:PrefixIndex/Draft .  They can be moved back into the Draft space if desired.

Thank you Matt, Steven, and everyone else for your work on this. :-)