On Wed, Apr 3, 2013 at 3:30 AM, Ori Livneh &lt;ori(a)wikimedia.org&gt; wrote: mediawiki.org will still exist to document MediaWiki. The domain name itself makes it fairly ill-fit to document our non-MediaWiki software documentation. Wikitech, till recently, was a fishbowl wiki that required an operations-team member to create an account for anyone wanting to edit. Since being merged with labsconsole it has open registration and its authentication is integrated with a number of our developer and operations tools. All contributors must become at least partially familiar with wikitech anyway, since it's the registration location for commit access. That, along with its more generic name, better suit it for hosting our documentation for non-MediaWiki products. The biggest freedom a wiki provides is the ability to create your own structures and to change and modify those structures quickly and easily. Adding semantics gives you more freedom to create more interesting structures, especially if this is combined with proper templating. One example of how semantics could improve mediawiki.org is the extension matrix <https://www.mediawiki.org/wiki/Extension_Matrix>. That list is maintained by a bot. Its listing is completely inflexible. The bot is required because MediaWiki has no mechanism for handling this. Adding semantics to the extension pages would make the matrix a simple query. We could also add some statistics about extensions. It wouldn't require anything from the editor's side as the semantics are hidden away via templates. Editing extension pages could also be considerably easier, since the extension page could have a proper form for the templates. We will hopefully be able to use wikidata for things like this in the future. Spend some time editing a well designed Semantically enabled wiki. Web Platform is a good example: <http://docs.webplatform.org/wiki/Main_Page>. There's a high degree of structure there. That wiki is way above average quality from the point of view of a reader specifically because it enables the editor to easily make the content consistent. I think the level of structure on webplatform doesn't well suit something like wikitech or mediawiki.org, but adding some extra structure or at least adding semantics to existing structure will be very useful. - Ryan

On 04/03/2013 09:15 AM, MZMcBride wrote: As far as I know: mediawiki.org - MediaWiki software and extensions wikitech.org - system administration stuff for WMF production and labs Yes, there are a few things on the wrong side of the line (which should be fixed), but for the most part it seems pretty accurate. Matt Flaschen

On Apr 3, 2013, at 8:29 AM, Antoine Musso &lt;hashar+wmf(a)free.fr&gt; wrote: I'd rather we wait for wikidata. I'd eventually like to replace the SMW use on wikitech with wikidata as well. - Ryan

On 04/03/2013 11:58 AM, Yury Katkov wrote: +1 I haven't understood the resistance of the WMF to use SMW in more places, but putting it on MW.o would really make MW.o's non-WMF focus clear. Of course, if the WMF had some objective reason to avoid SMW, now would be a good time to clarify what those objections are. -- http://hexmode.com/ [We are] immortal ... because [we have] a soul, a spirit capable of compassion and sacrifice and endurance. -- William Faulker, Nobel Prize acceptance speech

Hey, That depends on how you defined "largest". If you want a list of public wikis (which of course is not complete) by property value count, then here you go: http://wikiapiary.com/wiki/Semantic_statistics SMW is used on many hundreds of wikis, including those of governments and large corporations. It has been out there for years. People seem to be using it very successfully. It also has by far the largest third party community next to core itself. From my perspective a lot of the concerns typically coming from people whenever WMF usage of SMW is in question are uninformed paranoia. And there seems to be a good deal of populism going on as well, since apparently in some WMF related circles it is cool to hate SMW. See also: some testimonials: https://semantic-mediawiki.org/wiki/Testimonials Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --

Hey, I'd say it's well informed paranoia. SMW is used on some largish wikis at SMW has historically had a touch of the featuritis. Most of its features I fully agree with you when speaking about Wikipedia or whatnot. SMW, like any software, has it's issues. Knowing these I think it'd be a bad idea to try to deploy it on Wikipedia or Commons or whatever in its current state. Wikitech and MediaWiki wikis are a different story though. The ill-informed paranoia I was referring to consists out of thinking something not far from "SMW will make any wiki uber-complicated and explode". This certainly does not include concerns with deployment on the big WMF project wikis, which should be taken seriously. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --

On 04/04/2013 03:22 AM, Jeroen De Dauw wrote: As a point of anecdotal data, I've used SMW with success at two of my past employers for semiautomated documentation of machine rooms and related documentation. Being able to make templates (mostly autofilled by facter) that allowed queries like "how much power is being used by rack C7" and "what boxen are currently still running Hardy" on our ops wiki, alongside the human-written documentation, was /invaluable/. This looks a lot like the scope of mwm and wikitech. So yeah; perhaps SMW has issues that makes deployment to the bigger content wikis problematic, but rejecting it for the smaller data-based ones on a kneejerk is, at best, misguided. -- Marc

On 04/04/2013 10:04 AM, K. Peachey wrote: I'm honestly not familiar enough with Wikidata to be able to tell how applicable it'd be to wikitech/mwm. My understanding of it is from a Wikipedia editor's point of view and I see it as "The place where data is stored in a language-independent manner and can be used by all content wikis in a way that resemble SMW without redundancy". It's not clear to me that mixing our technical data with the encyclopedic data is reasonable; or that we aren't going to be causing trouble if we try. Does it support some namespace-equivalent to segregate different data sets? -- Marc

On Wed, Apr 3, 2013 at 11:55 PM, Matthew Flaschen &lt;mflaschen(a)wikimedia.org&gt;wrote;wrote: point!

It seems that it's what's planning now, isn't it? Turn on SMW, Semantic Forms and maybe other semantic extensions and modify the existing templates to use them. On Wed, Apr 3, 2013 at 7:26 PM, Antoine Musso &lt;hashar+wmf(a)free.fr&gt; wrote:

On Wed, Apr 3, 2013 at 2:11 PM, Ori Livneh &lt;ori(a)wikimedia.org&gt; wrote: This isn't technically my proposal. It's Quim's, so he can likely better answer this. For webplatform the semantic design was implemented by a couple engineers in about 3-6 months. - Ryan

On 03/04/13 19:37, Quim Gil wrote: User profiles are not that helpful. They may serve to bring some folks together and it'd probably be nice for those folks to have them, but adding forms and templates and further complexity for that is not something most of us need or want. Using something like SocialProfile might be a good way to get it set up quickly if you really want it, but anything more would entail resources better spent elsewhere. Specified projects and tasks add bureaucracy and make it harder for folks to jump in and just fiddle with things. You see the same ideas rejected time and again on wikipedia and other projects for precisely that reason. We do not need more confusing barriers, we need less - we need to be able to jump in and do stuff, or people will be less inclined to bother. There are plenty of things that definitely do need a nicer UI. Gerrit comes to mind, but UI is only part of it - and it is indeed probably the biggest barrier we have that new contributors and old alike face. I would seriously suggest addressing that /before/ getting into the details of what brings folks into the fold in general. And yes, I know what you said about gerrit being upstream and having its own community and issues and all that, but when the entire platform is flawed from the ground up, perhaps there are other things to consider. If the only way to resolve the problems it places on our community is to replace it, then we should seriously consider replacing it. And if there is nothing with which to replace it, then perhaps we should be using resources otherwise spent puttering around initial details to do so, because those initial details don't mean a whole lot even if they do help bring in more contributors... if said contributors still wind up crashing into the sludgy brick wall that is gerrit. Obviously I'm not terribly fond of gerrit, but it's not for lack of reason. Another active thread on this list demonstrates a piece of it. -- -— Isarra

On Wed, Apr 3, 2013 at 5:01 PM, Steven Walling &lt;steven.walling(a)gmail.com&gt;wrote;wrote: I think this is somewhat exaggerated. Almost all of the things proposed can likely be done by defining a set of semantic properties, modifying existing templates, then adding queries into templates that can be added back into the same templates we're already using on other pages. Defining forms is also relatively simple for all of this. I doubt much or any of this will requirement any development work. If we hire someone that already has a lot of SMW experience, this is likely a pretty easy target. We have a current system? Almost all of the changes Quim is suggesting will likely be completely transparent to you and your normal processes. Semantic annotations are almost always added to templates and users have no clue that magic is happening behind them. - Ryan

On Wed, Apr 3, 2013 at 5:31 PM, Steven Walling &lt;steven.walling(a)gmail.com&gt;wrote;wrote: Have you tried SMW? Unless you are heavily editing templates you won't need to relearn anything and neither will anyone else. The system is hidden from you behind normal MediaWiki templates. In many cases the templates are also editable via forms, which actually makes it far easier to edit than regular MediaWiki. If you are a content organizer that modifies templates and likes to make structures easier for for readers and editors, SMW actually makes it much easier to do things that are otherwise impossible in MediaWiki without inflexible bots. Writing bots is a lot harder than learning SMW. Are you also opposed to wikidata? The vast majority of what's being proposed for wikitech is functionality that will also be available at some point in wikidata. When that's available we can switch to that system, rather than SMW. - Ryan

On Wed, Apr 3, 2013 at 6:06 PM, Steven Walling &lt;steven.walling(a)gmail.com&gt;wrote;wrote: The proposal is to move non-MediaWiki documentation our of mediawiki.orginto a more generically named wiki. The proposal isn't for migrating all of mediawiki.org. - Ryan

On Wed, Apr 3, 2013 at 3:06 PM, Steven Walling &lt;steven.walling(a)gmail.com&gt; wrote: I think the potential migration of content to wikitech and the potential use of certain MW extensions to improve the user experience are legitimately separate issues. If the migration is merited, it is likely merited irrespective of whether we use SocialProfile, LQT, SMW, SMF, etc. We could perform a large migration of content without using any of them, or we could experiment with these extensions without/before migrating any content. I'm ambivalent about the migration of content. I'm not very fond of the current division between dev-ops contributors (wikitech) and everything else (mediawiki.org), which reinforces barriers between the two worlds. Those are the barriers that Labs was designed to tear down, empowering technical contributors to prototype their changes easily, and to get them ready for large-scale usage on Wikimedia or other production sites. Having all technical contributors directed to wikitech.wikimedia.org would address that - it would introduce them to a magical world of dev-ops unicorns and PHP rainbows at the same time. And having mediawiki.org more clearly dedicated to the product would allow it to shine more brightly in its own sunflower-y colors. At the same time, the amount of wiki-ping-pong we're playing with technically interested users could very well increase significantly as a result. Right now, wikitech.wikimedia.org is relatively quiet, with changes typically either being made by the Wikimedia ops team or by Labs users. It simply stands to reason that if we distribute a lot of content from a large wiki to a much smaller one, the number of times that you'll have to go back and forth between the two to find what you're looking for will increase. API docs? Over here. Status update? Over there. Extension installation docs? Over here. Specs related to the same extension? Over there. Ping, pong. Ping, pong. The divisions may seem logical to us, but for the confused technical contributor, things could easily get a lot worse. If feasible, I would at the end of the day still argue in favor of a single consolidated technical wiki. I realize calling that wiki mediawiki.org is not ideal, but beyond the domain name, a lot can be done to provide reasonable divisions (namespaces, navigation, etc.), so that MediaWiki the product and other Wikimedia technical projects and processes are clearly distinct. Let's also not forget that we'll have future potential for new MediaWiki-related technical contribution that actually would fit very nicely under the mediawiki.org umbrella (e.g. Lua script repository, gadget repository). If we do go forward with the migration to wikitech.wikimedia.org, I would argue in favor of largely depleting mediawiki.org of content except for clearly necessary end user documentation and support pages, to minimize ping pong effects. Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

On 04/04/2013 12:10 AM, Erik Moeller wrote: In theory yes, but in practice there are some associations: * Contributors and the docs relevant for them should be in the same place. * Semantic MediaWiki is required to prototype and implement the features proposed for contributors in the quickest and simplest way. Unless someone has a better idea. * http://mediawiki.org has the docs but not SMW. * http://wikitech.wikimedia.org has SMW but not the docs. As far as I can see it is impossible to solve the puzzle without changing something and upsetting someone. The scenarios are: 1. Move the right content to Wikitech and experiment there with SMW. When Wikimedia has a better solution, take it. 2. Install SMW in mediawiki.org and experiment there. When Wikimedia has a better solution, take it. 3. Keep everything as it is. Wait for Wikidata, Flow and Global Profile to be ready to help us here. 4. Create a new website just for this. :P If you have a 5th please share it. 3 or 4 would be the usual choices out there. I believe we would be in trouble with any of both. I'm ambivalent between 1 or 2, only fearing that having so many strong & opinionated positions we don't end up trying a 2.5 headed for failure (another usual choice out there). But I have hope in this discussion and our capacity to end up doing The Right Thing. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

On Thu, Apr 4, 2013 at 11:21 PM, Quim Gil &lt;qgil(a)wikimedia.org&gt; wrote: Thanks for these edits Quim, especially adding specific questions you're trying to answer with each feature/iteration. I think separating out the wiki migration issue and prototyping new features on wikitech is a good way to diffuse any stress around either question. This is a much better way to move forward, and I'm happy to help try out any features related to structured user pages, projects, events, etc. when you're ready for that. Steven

On 04/05/2013 03:19 PM, Quim Gil wrote: In fact I kept doing changes until settling with http://www.mediawiki.org/wiki/Project:New_contributors The problem is still the same. All the discussion last week didn't touched it a bit. The vision or long term solution wasn't contested much either, since most of the discussion was (simplifying a lot) about URLs and extensions. The tactics have changed radically, though: let's focus on the tasks that can be done here and now with existing tools. Contributions welcome. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

On 04/09/2013 10:42 AM, Yury Katkov wrote: http://www.mediawiki.org/wiki/Project_talk:New_contributors please, as you already did. :) Thanks! -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

Hey, I don't support moving to Semantic MediaWiki, That is incorrect. SMW does not force users to learn new things. I imagine that the setup Quim has in mind does not involve workflows for basic documentation tasks that require users going though them to have knowdlge of SMW. In fact, I suspect the workflow will be made easier for users by making use of forms and whatnot, rather then forcing them to mess with templates and updating some list on some other page. If you don’t like the software - fine, but please do not try to scare people away with disinformation. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --

Thank you for the vivid discussion about the potential future roles of http://mediawiki.org and http://wikitech.wikimedia.org I have updated http://www.mediawiki.org/wiki/Technical_communications/Dev_wiki_consolidati… accordingly. On 04/03/2013 03:51 PM, Steven Walling wrote: guillom, myself and whoever else wants to help. http://www.mediawiki.org/wiki/Technical_communications/Dev_wiki_consolidati… -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

Keeping a single wiki seems to be the most sensible approach. I agree with Erik that there are good ways to separate different types of content, such as namespaces, and I agree with Yuri that wikitech is the best choice of name, since it is a superset of mediawiki. I think we should agree on this first, and then decide whether we want the more ambitious, SMW-powered features (I am for them as well, btw). --Waldir On Thu, Apr 4, 2013 at 8:10 AM, Erik Moeller &lt;erik(a)wikimedia.org&gt; wrote: On Thu, Apr 4, 2013 at 8:58 AM, Yuri Astrakhan &lt;yastrakhan(a)wikimedia.org&gt; wrote:

On Wednesday, April 3, 2013 at 3:40 PM, Quim Gil wrote: I'm not at all concerned about the rate at which you iterate -- it isn't about how fast you put out the shiny and new, but whether the assumptions that motivate this big undertaking are testable and falsifiable. Before we can say anything with confidence about what newcomers truly need, we need to do some usability testing and research. Because newcomers are generally voiceless, there is an unconscious tendency to project onto them a set of subjective preferences and intuitions, and the only way around that is data. -- Ori Livneh

Hi, I don't know if this is useful in this context but because of the term "usability testing" I thought this extension might be interesting for you: http://www.mediawiki.org/wiki/Extension:UIFeedback This project is still under development and we haven't gotten through code and design review yet… --Claudia

On Wed, Apr 3, 2013 at 9:06 AM, MZMcBride &lt;z(a)mzmcbride.com&gt; wrote: Maybe I'm missing something, but what about the MediaWiki page creation process isn't "find a page, click edit, and just type into it"? *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo(a)gmail.com

Hi, about Wikitech / mediawiki.org check http://www.mediawiki.org/wiki/Technical_communications/Dev_wiki_consolidati… On 04/03/2013 12:30 AM, Ori Livneh wrote: Sure, but following this argument we could just have dev.wikipedia.org, right? The point is that we need a good ground to build an infrastructure for technical contributors, and Wikitech provides this ground. It is not such a radical step, actually. Today we are asking contributors to * Join wikitech-l(a)lists.wikimedia.org * File bugs at bugzilla.wikimedia.org * Send patches to gerrit.wikimedia.org * ... after getting developer access at wikitech.wikimedia.org Moving / building there the resources related to contributors makes sense. I think the simplest way to draw the line between Wikitech and mediawiki.org is to do it between users and contributors. The definition of "user" includes * Editors of a generic MediaWiki. * Sysadmins installing MediaWiki. * Developers using the MediaWiki API. I believe this causes no harm to mediawiki.org, cleaning it from Wikimedia centric content and allowing it a lot more freedom and focus about using MediaWiki and related technologies available to anybody. mediawiki.org keeps being the place to download software, learn and get support. None of these activities requires to put your feet in any Wikitech* or Wikimedia* domain. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

On 04/06/2013 12:38 PM, Lars Aronsson wrote: With hindsight, it was probably a mistake to make the names so similar. I do think there should be distinct names. Wikimedia has great projects that are not an encyclopedia. Matt Flaschen

On 04/03/2013 03:30 AM, Ori Livneh wrote: I don't know that it's appropriate to put WMF-only stuff on the MediaWiki site. Of course, I'm not totally convinced merging the other way is a good idea other. Although there's overlap between MW proper and the WMF tech, we have to remember they're distinct. Based on Ryan's email, a merge may not in fact be intended, though I agree that's what "wikitech.wikimedia.org would become the one and only site for our open source software contributors" sounded like. There is a role for the semantic web (e.g. Wikidata seems to be quickly heading in the right direction). At the same time, I agree that the wiki must not get in the way of simple writing. Matt Flaschen

On Wed, Apr 3, 2013 at 5:19 PM, Isarra Yos &lt;zhorishna(a)gmail.com&gt; wrote: Wikimedia's configuration isn't specified on MediaWiki.org. It's on wikitech already. The docs you are referring to are non-wikimedia configuration examples provided by MediaWiki users, and that stuff will stay there. - Ryan

On Wed, Apr 3, 2013 at 10:33 AM, Marc A. Pelletier &lt;marc(a)uberbox.org&gt; wrote: I totally support this. -Chad

Le 03/04/13 15:48, Yury Katkov a écrit : I fully support that separation, and I guess we can start moving the Wikimedia projects pages to wikitech. Example candidates: https://www.mediawiki.org/wiki/Category:WMF_Projects -- Antoine "hashar" Musso

On 03/04/13 14:48, Yury Katkov wrote: I disagree - many of the same resources are useful to either group, and there is also overlap even between the groups - developers focussing on Wikimedia stuff are more likely to create their own wikis due to their familiarity with the stuff, for instance, and they shouldn't need to go outside their comfort zone to get the relevant info on that specifically, and we should if anything be encouraging independent developers to get involved in the movement as well, since if they're using the software chances are they have at least some shared goals with Wikimedia, so we really should not be pushing them away. And since a lot of the stuff is applicable to either group, if the groups were separated, what then? What would determine which wiki something would go on, or would it just be duplicated across both? And if the latter, who is going to update the other when information is updated on one? In such cases one usually seems to just wind up stagnating, and it's not a good model. -- -— Isarra