I don't agree with some of the things you think should be moved to wikitech. The API and development tutorials almost completely belong on MediaWiki.org. Developer access and such also probably belong here.
Talk:Technical communications/Dev wiki consolidation
Where to draw the line
I was also hesitating. Before discussing the outcome let's try to agree on the principle: what is your reasoning to keep API and dev tutorials in mediawiki.org?
If Wikitech is all about OSS contributors and mediawiki.org focuses on MediaWiki users (as in sysadmins and editors) then we can assume that API docs and dev tutorials fit into Wikitech.
It is true though that you can use those for pure 3rd party development ending in proprietary extensions etc. And those 3rd party developers could also be considered "users" of the MediaWiki API. Still, even those developers will benefit from the proximity with the maintainers and core developers at Wikitech... That was the main reason that made me propose it within the scope of Wikitech.
Then again I have no strong opinion, as long as we agree on the principles. Whatever works better for the actual developers. And perhaps most of the problem can be solved with landing pages linking to the right resources in each site. For instance How to contribute is a clear candidate for Wikitech but this doesn't mean that we can't have it also in mediawiki.org, pointing to Wikitech pages.
MediaWiki.org should be able the MediaWiki software. That includes sysadmins and editors, but also extension development and API stuff outside of a Wikimedia context.
For the API documentation specifically it's really easy to say that it's definitely more relevant to mediawiki.org - the API is part of the MediaWiki software and is found on all third-party wikis.
Ok, so what about this principle:
3rd party developers are also MediaWiki users and this is why their related docs are in mediawiki.org. As soon as they start contributing patches to projects hosted at http://gerrit.wikimedia.org or https://github.com/wikimedia they become contributors, and therefore the specific documentation for that is hosted at Wikitech.
That could make sense as well. With a couple of links from one wiki to the other we could get good coverage in both, without duplication. Waiting for more feedback.
No. Just say that everything related to MediaWiki (not excluding MediaWiki development) goes on mediawikiwiki instead of wikitechwiki. Everything which is only useful in the context of wikimedia (wikimedia engineering tasks etc.) can go to wikitechwiki. It should not be divided on the basis of user|contributor.
But having "one site" for contributors is the main motivation of this shuffling. Having "one site" for developers is a good thing as well for any project, as developers know well. Having contributor/devel documentation in one site or another depending on 3rd party adoption doesn't make much sense.
The Wikitech proposed is not about Wikimedia-only stuff. In fact the division line Wikimedia-only vs 3rd-party-only can't be good, right?
Use vs contribute is a sane division of roles seen in many OSS projects. Since all contributors are users, it promotes the cross-pollination of people between both sites. Having a Wikimedia vs MediaWiki division is a lot more dangerous since it may create a real divide.
Why do you assume contributors and developers are different people? Why do you assume bot operators cannot also be third-party sysadmins, and that neither of those will be developers? Such are often developers. Even when they aren't, the development stuff is useful - you need to know what you're installing, and extensions are just as relevant as the api documentation when writing a bot, because you have to know the framework, and if the framework is lacking, that's when a bot person turns into a developer as well.
And that, I thought, was precisely why it's all here - because these things are all connected. It's organised such that there are resources friendly to users, but such that they can find more information and follow relevant development as well if they want to, and visa versa. Labs was mostly separate for security reasons or something along with the whole labs part not being specific to mediawiki, and wikitech was this internal thing specific to the WMF that everyone else just sort of ignored. So if mediawiki things are truly to be split (sure, they're already split, but I mean such that the rest of us notice), that would just make what is where more confusing. To expect most folks to not ignore one or the other would be about as ridiculous as expecting en.wikipedians to come to mw.org for information about new features (and that is completely ridiculous, in case you were wondering - 'insane' or 'suicidal' would be terms for it), because there is simply no good way to watch multiple wikis or coordinate across them - and for something like this, why should there be? Is mw.org getting too big or something?
Yes, same people may combine different roles. It happens all the time, and still people find their way through different sites as long as it is clear the domain covered by each one.
We are not trying to create two segregated sites. Everything is still a click away. As long as each domain is clear we should be fine. Interwiki redirects (i.e., allowing #REDIRECT wikitech:foo to work automatically), common search and RSS/Atom must be explored to bridge and connect wherever makes sense.
BUT what is more important: I have the feeling that we don't agree on the problem. In order to agree on solutions we need to agree on the problem first.
If the most problematic point of this proposal is the location of certain pages then the best is to be conservative moving content from mediawiki.org to Wikitech. We can keep the docs interesting for "independent developers" in mediawiki.org.
There is enough change to do before reaching that point. Once we are there we can look around and decide whether it is worth moving anything else or not.
If there is agreement about this then I can just edit accordingly Technical_communications/Dev_wiki_consolidation#What_belongs_where accordingly.
I'm all for making things related to MediaWiki and WMF sysadmin work saner, but I'm not sure whether this is the correct way to go about it. Instead of further spreading information between these two wikis — MediaWiki.org and Wikitech — we should be considering consolidating information into one place for easy accessibility. Not just for our sake, but for our users' sake.
Technical communications/Dev wiki consolidation#Proposed solution tries to justify this split by comparing the situation to the mailing lists, but that's a rather bad comparison, given that the mailing lists have been around for (over) 10 years. Sometimes mistakes happen and they may not be easy to fix or people may not even think much of it. Personally, the way I see it, MediaWiki-l is for new users' general questions and whatnot — maybe someone really does prefer mailing lists over on-wiki support desks and whatnot — whereas wikitech-l is for current and future development, wild proposals and other crazy ideas.
Splitting MediaWiki.org into a user-oriented and a developer-oriented wiki possibly can't be good for anyone. We're not a commercial project, there's no reason to have the developer docs on a separate site. MediaWiki.org is a giant hub for all things MediaWiki and many of us like it just that way, as it gives us a nice overview of what's going on where, how I could help (GSoC, OPW, etc.) and so on.
WMF engineering pages, reports and plans here are somewhat of an oddball, but they're still relevant, because the WMF is the single biggest user and developer of MediaWiki and many profilic developers — former volunteers — are current Foundation employees and all.
On the other hand, what about things relevant only to a certain party, such as ShoutWiki, Wikia or wikiHow? If the information is useful, MediaWiki-related and possibly helpful for others struggling with similar issues, then MediaWiki.org should be the place for that kind of info.
tl,dr: One wiki to rule them all; let that wiki be MediaWiki.org and merge everything else into it instead of moving pages from it.
I'm not sure I like the merging Idea.
Basically, I would like MediaWiki as a project to be able to stand on its own 2 feet, and hence be independent of what Wikimedia or anyone else is doing with it. If MediaWiki became simply a subproject of Wikimedia's various technical initiatives, I think that would be sad. (OTOH perhaps that has already happened...). I worry that merging the wikis would be a step in that direction.
Note, I do believe that Wikimedia team reports should be on whatever wiki primary dev documentation for MediaWiki is, since they are team reports about people hacking MediaWiki. On a similar note, if somebody (ShoutWiki, Wikia, etc) put together a team to add some major feature to mediawiki, I think it would be entirely appropriate to have their team reports on the mediawiki dev wiki too.
I still think the using / contributing line could be applied in the location of the reports. For example:
- VisualEditor software announcements and release notes would be in mediawiki.org, where the software can be downloaded.
- VisualEditor team status reports would be in Wikitech, where the software is being developed.
The same would apply to extensions or other projects maintained by non-WMF developers, as long they are using the same contribution infrastructure (Bugzilla, Gerrit, etc) and they publish their releases in mediawiki.org.
If still you want to see some of the info in the other wiki as well, then we could make a better use of RSS/Atom.
If you don't clearly state that all this won't affect documentation for users if MediaWiki sites (including Wikimedia projects users), I strongly Oppose this, in particular "Move technical content from Meta" and "Invite the English Wikipedia technical community to join as well with their content" (why only English Wikipedia by the way).
That would go against bugzilla:43591 and any attempt to make the MediaWiki docs usable, and will fail miserably anyway for m:not my wiki + separation from main docs + being an island outside SUL (and not a m:Wikimedia project).
The true problem for user documentation is centralising it on a single wiki and keeping it up to date and translatable, from the current situation where it's scattered on hundreds of wikis: the path of least resistance has to be followed for this, and anyway MediaWiki core can link only to mediawiki.org.
The proposal is to keep user documentation where it is now. The discussion is about developer documentation.
The references about Meta and enwiki are also about generic developer docs. If there are more of those in other languages, the principle would apply as well. The idea is simple: developer docs that are useful beyond your own project could be more useful when shared and maintained in the common site.
Thank you for pointing to the confusion. I have edited Technical_communications/Dev_wiki_consolidation#Steps to make it more clear.
Why reuse wikitech.wikimedia.org
In the risks section, it is admitted that splitting could be seen as a WMF-/non-WMF-break. So why not use dev.mediawiki.org (or somesuch) for the developer site? Appearances can be everything.
We want less wikis, no more...
Wikitech has a user login integrated with labs, Gerrit and maybe Bugzilla someday. For several reasons it is not the universal login shared across the Wikimedia family. Also for several reasons doesn't have the same MediaWiki version that is deployed to Wikimedia servers.
Having dev.mediawiki.org might be nicer (for some?) in the surface but still would require different login, different wiki. That would confuse people a lot more than the solution proposed.
Today we are asking contributors to
- Join email@example.com
- File bugs at bugzilla.wikimedia.org
- Send patches to gerrit.wikimedia.org
- ... after getting developer access at wikitech.wikimedia.org
This situation is perceived as normal today, and I believe the proposed solution will be perceived as normal as well, as soon as we get over the initial reaction.
But why not rename the new wikitech.wikimedia.org to dev.mediawiki.org? It's just a DNS entry, right?
Because we're not just doing development here. We're doing operations work, running bots and tools, doing project planning etc. wikitech is more generic and as such encompasses all of that.
And I would still stick to the solution proposed below the line you quoted: That won't happen if the whole community of contributors (WMF or not) agrees to make Wikitech their new home. As said most of the current members have already a *.wikimedia.org account and I'm pretty sure things will be fine when the dust settles and we have a better plans thanks to all the feedback, and when we start moving pieces, nothing falls and we start experiencing the benefits of the new situation.
The problem with "appearances" is stronger with current community members with opinions about labels like "MediaWiki" or "Wikitech" than for the people out there. Most of the newcomers only know about "Wikipedia" anyway. For those willing to make a technical contribution, a label like "Wikitech" will sound just fine.
I don't know; I get alarm bells ringing. While I appreciate Ryan's point, it just says to me "we're going to be making a Wikimedia Operations site (wikitech) the MediaWiki development hub". Okay, so we don't actually *have* many upstream contribution from non-Wikimedian reusers, but this is surely this is (or at least appears) to be an admission of failure in that regard. What I liked about the original proposal was its potential to create a natural "MediaWiki development" site that was at least notionally not 100% WMF...
Actually, what I was saying was that we do a lot of non-mediawiki development, some of which is operations development. We currently must stick all of that project documentation on mediawiki.org, where it doesn't belong. In fact, Wikimedia's project planning doesn't really belong on mediawiki.org as a whole.
We already need to split our documentation between two wikis. wikitech is a good location for project planning and non-wikimedia development work. mediawiki.org would still be the place for documenting mediawiki, though (like api docs, extension docs, config options, configuration examples, etc.).
The difference being that, currently, only ops are affected by the docs split (they sometimes have to look on wikitech instead/too), for all the others "everything" is here. For user documentation of course it's worse because there's still a lot of friction and it's all scattered on Meta and hundreds of local wikis.
Except you're thinking from a very Wikimedia point of view. For third parties mediawiki.org is full of unrelated content that makes it harder to actually find MediaWiki documentation.
Why do you think the allegedly unrelated content makes it harder to find docs? It's very easy, docs should be only in Extension, Help and Manual namespaces. Sure, some don't respect namespace separation, but they'd respect wiki separation even less.
You started this thread pointing to an emotional reaction and I still think this is mostly a discussion driven by current contributors' emotions more than by the actual needs of users and developers. The fact is that finding or not finding the information you are looking for is a problem of content architecture and search tools. The role played by a domain name and a logo is secondary, especially if your website is a mess. And anyway the main risk is that users will end up first in an outdated answer at Stack Overflow or some obscure mailing list archive that Google decides to promote.
For the current discussion we could agree that a good solution could be designed and implemented at mediawiki.org, Wikitech, both or elsewhere. What we need to agree first is in the definition of the problem and the priorities to solve it. There is an Issue described. Do you agree or can you improve that description?
The Steps section should make an explicit mention to the wikitech.wikimedia.org and mediawiki.org homepages. Both will require a non-trivial amount of work to reflect the new reality. All the better if they even look nice and contemporary after the overhaul. ;)
What about eliminating another subdomain:
doc.wikimedia.org ---> wikitech.wikimedia.org/docs
The /docs (or /doc) subdirectory is quite conventional and it could have the same header/footer as the rest of Wikitech.
docs.wikimedia.org doesn't resolve for me...
MediaWiki core docs should be under mediawiki.org. Puppet docs should be under wikimedia.org. VisualEditor docs should probably be under wikimedia.org as well, at least for now.
... and Meta as well
This proposal should also mention the end of meta:Wikimedia developer hub and other developer documentation hosted there.
That page is just a "portal" to access nothing. However, note that PWB docs were moved to mediawiki.org from Meta and should not go anywhere else.
Would this fit the principle of "keeping docs relevant to independent developers at mediawiki.org"?
Yes, but what are the docs on this wiki that are not? Do you have examples?
Also, half of this proposal seems to be based on the assumption that SMW can't be installed on this wiki and that any amount of manual work between 0 and +infinite is acceptable to get SMW by mass migration... is it so hard to install SMW? translatewiki.net installed it with a one-man effort, it sometimes gives problems but if the WMF is unable to find someone keeping an eye on SMW on a single wiki to avoid explosions then the situation is very sad. (Edit: Erik had already said most of what I meant to say, sorry.)
Spinning off this proposal from Contributors
After reading this page it makes total sense to concentrate here the one wiki discussion. Even if it's an important factor at the Contributors proposal it is a proposal on its own, and it would make sense to reach to a conclusion about it even if the way to organize contributors wasn't defined.
I will remove the one wiki details there and simply add a link here.
I'm afraid that splitting them will make this one a blocker to the other. My current understanding is that I will be able to help with this proposal in an advisory capacity, but someone else will need to lead its implementation, including the long discussion phase with the rest of the community.
We can discuss the best way of doing this, of course.
If they are in a same proposal they are anyway a blocker of the other, so if that happens we don't lose anything. :)
I'm happy driving the discussion in both and make the connections where needed. But they are technically different things and splitting makes every discussion more manageable.
OK; I just wanted to let you know :)