I have been drafting a proposal to attract new contributors, help them settle in, and connect them to interesting tasks. It turns out that many of these problems are not unique to new contributors. We suffer them as well and we are just used to them.
The proposal has evolved into a deeper restructuring of our community spaces. We're still drafting it, but a round of wider feedback is welcome before opening the official RFC at
https://www.mediawiki.org/wiki/Requests_for_comment/Wikitech_contributors
In summary:
* wikitech.wikimedia.org would become the one and only site for our open source software contributors, powered by semantic software and an ontology of categories shared across wiki pages, Bugzilla and hopefully Gerrit.
* Semantic user profiles would identify interests, project membership and preferences so users could get notifications about specific topics.
* Nodes would automatically structure links to the key information about a specific topic: wiki pages, events, news, projects, bug reports, Gerrit changesets, related contributors, and people interested.
* All project teams, whoever is in them, would have a standard way to report goals, members, tasks and updates.
The proposal includes a draft plan for a first iteration, including contracting out some software development and redesigning part of wikitech and mediawiki.org.
Your feedback is welcome at the discussion page. I will be consolidating there any feedback received here or through other channels. The official RFC should follow pretty soon, maybe next week.
On Tuesday, April 2, 2013 at 5:45 AM, Quim Gil wrote:
I have been drafting a proposal to attract new contributors, help them settle in, and connect them to interesting tasks. It turns out that many of these problems are not unique to new contributors. We suffer them as well and we are just used to them.
The proposal has evolved into a deeper restructuring of our community spaces. We're still drafting it, but a round of wider feedback is welcome before opening the official RFC at
https://www.mediawiki.org/wiki/Requests_for_comment/Wikitech_contributors
In summary:
- wikitech.wikimedia.org (http://wikitech.wikimedia.org) would become the one and only site for our open
source software contributors, powered by semantic software and an ontology of categories shared across wiki pages, Bugzilla and hopefully Gerrit.
That seems wrong. Of the two, MediaWiki.org is clearly the more successful wiki. It is larger by all measures, and draws a wide pool of active contributors. This is reflected in the quality of the documentation, which (pace self-deprecating humor) tends to be quite good. Up until recently a good portion of the links on Wikitech's main page pointed to content that was flagged as obsolete. It has come some way since then, but not quite enough to subsume mediawikiwiki.
The core of MediaWiki is in my mind still radical and exciting: you make or find a page, click edit, and just type into it. This seems to have gotten buried over the years under a pile of bad ideas and bad implementations, and skewered from the outside by MegaTronEditKillerLaserBot2000 and the like. The solution is not to pile additional layers on top, but to excavate MediaWiki from underneath them and make it fast as hell and simple, so that it once again feels like a dangerous, underspecified, liberating idea. Semantic this-and-that and ontologies of categories entails putting up rails everywhere and signs with arrows on them indicating which way you should go. That approach will inevitably end up reflecting a narrow, inflexible view of what a wiki is and what you do with it. And all the while MediaWiki will creak and groan from underneath.
-- Ori Livneh
On Wed, Apr 3, 2013 at 3:30 AM, Ori Livneh ori@wikimedia.org wrote:
On Tuesday, April 2, 2013 at 5:45 AM, Quim Gil wrote:
I have been drafting a proposal to attract new contributors, help them settle in, and connect them to interesting tasks. It turns out that many of these problems are not unique to new contributors. We suffer them as well and we are just used to them.
The proposal has evolved into a deeper restructuring of our community spaces. We're still drafting it, but a round of wider feedback is welcome before opening the official RFC at
https://www.mediawiki.org/wiki/Requests_for_comment/Wikitech_contributors
In summary:
- wikitech.wikimedia.org (http://wikitech.wikimedia.org) would become
the one and only site for our open
source software contributors, powered by semantic software and an ontology of categories shared across wiki pages, Bugzilla and hopefully Gerrit.
That seems wrong. Of the two, MediaWiki.org is clearly the more successful wiki. It is larger by all measures, and draws a wide pool of active contributors. This is reflected in the quality of the documentation, which (pace self-deprecating humor) tends to be quite good. Up until recently a good portion of the links on Wikitech's main page pointed to content that was flagged as obsolete. It has come some way since then, but not quite enough to subsume mediawikiwiki.
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 core of MediaWiki is in my mind still radical and exciting: you make or find a page, click edit, and just type into it. This seems to have gotten buried over the years under a pile of bad ideas and bad implementations, and skewered from the outside by MegaTronEditKillerLaserBot2000 and the like. The solution is not to pile additional layers on top, but to excavate MediaWiki from underneath them and make it fast as hell and simple, so that it once again feels like a dangerous, underspecified, liberating idea. Semantic this-and-that and ontologies of categories entails putting up rails everywhere and signs with arrows on them indicating which way you should go. That approach will inevitably end up reflecting a narrow, inflexible view of what a wiki is and what you do with it. And all the while MediaWiki will creak and groan from underneath.
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
Ryan Lane 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.
I follow Wikimedia pretty closely and I have no idea what the distinction between the two wikis (wikitech.wikimedia.org and mediawiki.org) is nowadays. I used to know as it used to be much clearer. Now I have no idea.
I think we should establish a bright-line rule for the wikis or merge them. The current situation seems pretty bad and it seems like it's only going to get worse with time.
MZMcBride
On 04/03/2013 09:15 AM, MZMcBride wrote:
Ryan Lane 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.
I follow Wikimedia pretty closely and I have no idea what the distinction between the two wikis (wikitech.wikimedia.org and mediawiki.org) is nowadays. I used to know as it used to be much clearer. Now I have no idea.
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
Le 03/04/13 11:18, Ryan Lane a écrit :
One example of how semantics could improve mediawiki.org is the extension matrix https://www.mediawiki.org/wiki/Extension_Matrix.
Can't we get Semantic extensions deployed on mediawiki.org ?
On Apr 3, 2013, at 8:29 AM, Antoine Musso hashar+wmf@free.fr wrote:
Le 03/04/13 11:18, Ryan Lane a écrit :
One example of how semantics could improve mediawiki.org is the extension matrix https://www.mediawiki.org/wiki/Extension_Matrix.
Can't we get Semantic extensions deployed on mediawiki.org ?
I'd rather we wait for wikidata. I'd eventually like to replace the SMW use on wikitech with wikidata as well.
- Ryan
On Wed, Apr 3, 2013 at 7:41 PM, Ryan Lane rlane32@gmail.com wrote:
On Apr 3, 2013, at 8:29 AM, Antoine Musso hashar+wmf@free.fr wrote:
Le 03/04/13 11:18, Ryan Lane a écrit :
One example of how semantics could improve mediawiki.org is the
extension
Can't we get Semantic extensions deployed on mediawiki.org ?
I'd rather we wait for wikidata. I'd eventually like to replace the SMW use on wikitech with wikidata as well.
Why? SMW is already here, it's documented beautifully, it has good performance, active community and it is NOT developing by Wikimedia Foundation, which is good political decision for the MediaWiki.org portal which aimed to be closer to 3rd party developers.
- Ryan
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 04/03/2013 11:58 AM, Yury Katkov wrote:
Why? SMW is already here, it's documented beautifully, it has good performance, active community and it is NOT developing by Wikimedia Foundation, which is good political decision for the MediaWiki.org portal which aimed to be closer to 3rd party developers.
+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.
Mark A. Hershberger wrote:
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.
If the Wikimedia Foundation put Semantic MediaWiki on MediaWiki.org, that would mean that the Wikimedia Foundation would be committing itself to supporting it indefinitely. While there is an active Semantic MediaWiki community, this likely isn't an issue. But if, in a year or two, there's nobody else willing to help out and Semantic MediaWiki breaks, it'll be the Wikimedia Foundation's responsibility to fix MediaWiki.org. Plus there's Wikidata to consider. I can understand the hesitation here.
Of course, if the WMF had some objective reason to avoid SMW, now would be a good time to clarify what those objections are.
According to https://wikitech.wikimedia.org/wiki/Special:Version, the Wikimedia Foundation is now using Semantic MediaWiki (at least on a limited basis). Most of the XSS/CSRF-type security issues have been resolved at this point, I think. I think the general concern has been scalability and perhaps relatedly the ability of users to execute poorly optimized queries (maliciously or otherwise). But take this with a grain of salt as I don't follow Semantic MediaWiki very closely. Out of curiosity, what's the largest wiki to use Semantic MediaWiki?
MZMcBride
Hey,
Out of curiosity, what's the largest wiki to use Semantic MediaWiki?
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. --
On Thu, Apr 4, 2013 at 2:15 AM, Jeroen De Dauw jeroendedauw@gmail.comwrote:
Hey,
Out of curiosity, what's the largest wiki to use Semantic MediaWiki?
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.
I'd say it's well informed paranoia. SMW is used on some largish wikis at Wikia and it apparently causes issues very often. The largest wiki with SMW at Wikia is very small in comparison to a lot of WMF wikis.
SMW has historically had a touch of the featuritis. Most of its features would need to be disabled on WMF wikis due to performance reasons, and then what's the point?
- Ryan
Hey,
I'd say it's well informed paranoia. SMW is used on some largish wikis at
Wikia and it apparently causes issues very often. The largest wiki with SMW at Wikia is very small in comparison to a lot of WMF wikis.
SMW has historically had a touch of the featuritis. Most of its features
would need to be disabled on WMF wikis due to performance reasons, and then what's the point?
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:
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.
Thank you for this. I still don't understand all the issues involved, but knowing that someone with intimate familiarity with SMW thinks it isn't appropriate for large WMF deploys helps.
I'm still wondering about wikitech/MW.o, but it looks like Quim Gil has asked the SMW community for input on that front, so I'm happy. (Not that my happiness should be anyone else's goal.)
Mark.
On 04/04/2013 03:22 AM, Jeroen De Dauw wrote:
"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.
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 Thu, Apr 4, 2013 at 11:59 PM, Marc A. Pelletier marc@uberbox.org wrote:
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.
It wasn't knee jerk the time it was discussed, and a few subsequent. There was some known problems with the code, Most of these should be cleaned up now since ryan is willing enough to run it on labs.
Plus we already have another system that is getting worked on and rolled out to a few of the production wikis that will seem to do similar features (based on comments in this thread already).
On 04/04/2013 10:04 AM, K. Peachey wrote:
Plus we already have another system that is getting worked on and rolled out to a few of the production wikis that will seem to do similar features (based on comments in this thread already).
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 04/03/2013 11:58 AM, Yury Katkov wrote:
Why? SMW is already here, it's documented beautifully, it has good performance, active community and it is NOT developing by Wikimedia Foundation, which is good political decision for the MediaWiki.org portal which aimed to be closer to 3rd party developers.
Software development of Wikidata is actually primarily by Wikimedia Deutschland.
Matt Flaschen
On Wed, Apr 3, 2013 at 11:55 PM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
On 04/03/2013 11:58 AM, Yury Katkov wrote:
Why? SMW is already here, it's documented beautifully, it has good performance, active community and it is NOT developing by Wikimedia Foundation, which is good political decision for the MediaWiki.org portal which aimed to be closer to 3rd party developers.
Software development of Wikidata is actually primarily by Wikimedia Deutschland.
Matt Flaschen
that's right, and software development of SMW is not by WMF, that's my
point!
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I'm not sure I understand your point. If it's better for mediawiki.org to have a non-WMF extension doing this, and neither SMW nor Wikidata are developed by WMF, how is SMW a better choice than Wikidata?
Alex Monk
On 03/04/13 21:23, Yury Katkov wrote:
On Wed, Apr 3, 2013 at 11:55 PM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
On 04/03/2013 11:58 AM, Yury Katkov wrote:
Why? SMW is already here, it's documented beautifully, it has good performance, active community and it is NOT developing by Wikimedia Foundation, which is good political decision for the MediaWiki.org portal which aimed to be closer to 3rd party developers.
Software development of Wikidata is actually primarily by Wikimedia Deutschland.
Matt Flaschen
that's right, and software development of SMW is not by WMF, that's my
point!
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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 hashar+wmf@free.fr wrote:
Le 03/04/13 11:18, Ryan Lane a écrit :
One example of how semantics could improve mediawiki.org is the
extension
Can't we get Semantic extensions deployed on mediawiki.org ?
-- Antoine "hashar" Musso
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wednesday, April 3, 2013 at 2:18 AM, Ryan Lane wrote:
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.
OK, given your experience with Web Platform, I'd like to get your assessment of what sort of engineering and design effort was required. What you are proposing is considerably more ambitious in scope (Web Platform doesn't integrate with bug management and SCM), but some napkin cost analysis could be very useful. Web Platform has very good usability and design. Even if the basic blocks for a semantically-enabled wikitech are there, there is still a large additional investment of designer time and effort that would be needed to make it usable and well-integrated. But how much? (Input from designers would be useful, too.)
The goal stated by this proposal is engagement of new contributors. Before committing to the full scope of the project, it would be good to comb through this and identify one or two things that could be implemented easily and that would be expected to demonstrate a measurable impact on the number of new contributors. We should not wait for a project like this to be finished in toto before examining the correctness of the initial hypotheses.
Ori
On Wed, Apr 3, 2013 at 2:11 PM, Ori Livneh ori@wikimedia.org wrote:
On Wednesday, April 3, 2013 at 2:18 AM, Ryan Lane wrote:
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.
OK, given your experience with Web Platform, I'd like to get your assessment of what sort of engineering and design effort was required. What you are proposing is considerably more ambitious in scope (Web Platform doesn't integrate with bug management and SCM), but some napkin cost analysis could be very useful. Web Platform has very good usability and design. Even if the basic blocks for a semantically-enabled wikitech are there, there is still a large additional investment of designer time and effort that would be needed to make it usable and well-integrated. But how much? (Input from designers would be useful, too.)
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 04/03/2013 11:11 AM, Ori Livneh wrote:
required. What you are proposing is considerably more ambitious in scope (Web Platform doesn't integrate with bug management and SCM), but some napkin cost analysis could be very useful.
Yes, but I didn't want to go too far with implementation details and budgeting before having some community feedback first (which we are getting now).
Then again, the proposal has enough level of detail to get a rough budget.
Before committing to the full scope of the project, it would be good to comb through this and identify one or two things that could be implemented easily and that would be expected to demonstrate a measurable impact on the number of new contributors. We should not wait for a project like this to be finished in toto before examining the correctness of the initial hypotheses.
Agreed.
http://www.mediawiki.org/wiki/Requests_for_comment/Wikitech_contributors#Fir... is supposed to be completed in 3 months, and even there you have some easier tasks that could be implemented pretty fast, namely forms & templates for
* User profiles. * Projects. * Tasks. * Events.
Notifications still require more definition and expertise to decide what should be done now. Is Echo ripe for this? Is it worth to use this experiment to prototype Flow there? Or should we fallback to a system like http://www.mediawiki.org/wiki/Extension:TranslationNotifications ...?
And then we have Nodes, which is a novel concept and probably requires more complex implementation work in therms of software development and design.
About design and usability... Yes, doing something amazing takes a long time (look at ourselves). Then again, this is parallel work. This project is not contesting Vector, neither the current look & feel. This proposal is first and foremost about the plumbing behind.
If you feel that more design resources / budget should be allocated on a nicer UI then I can also ask for it, but in a context of limited resources the priorities would be clear.
On 03/04/13 19:37, Quim Gil wrote:
http://www.mediawiki.org/wiki/Requests_for_comment/Wikitech_contributors#Fir... is supposed to be completed in 3 months, and even there you have some easier tasks that could be implemented pretty fast, namely forms & templates for
- User profiles.
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.
- Projects
- Tasks.
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.
If you feel that more design resources / budget should be allocated on a nicer UI then I can also ask for it, but in a context of limited resources the priorities would be clear.
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.
On Wed, Apr 3, 2013 at 11:37 AM, Quim Gil qgil@wikimedia.org wrote:
Agreed.
http://www.mediawiki.org/wiki/**Requests_for_comment/Wikitech_** contributors#First_iterationhttp://www.mediawiki.org/wiki/Requests_for_comment/Wikitech_contributors#First_iterationis supposed to be completed in 3 months, and even there you have some easier tasks that could be implemented pretty fast, namely forms & templates for
- User profiles.
- Projects.
- Tasks.
- Events.
Notifications still require more definition and expertise to decide what should be done now. Is Echo ripe for this? Is it worth to use this experiment to prototype Flow there? Or should we fallback to a system like http://www.mediawiki.org/wiki/**Extension:**TranslationNotificationshttp://www.mediawiki.org/wiki/Extension:TranslationNotifications...?
And then we have Nodes, which is a novel concept and probably requires more complex implementation work in therms of software development and design.
About design and usability... Yes, doing something amazing takes a long time (look at ourselves). Then again, this is parallel work. This project is not contesting Vector, neither the current look & feel. This proposal is first and foremost about the plumbing behind.
If you feel that more design resources / budget should be allocated on a nicer UI then I can also ask for it, but in a context of limited resources the priorities would be clear.
Quim, I think even this first iteration is problematic on a bunch of fronts. 3 months as a first iteration to build several major features as the basic proof of concept should be a sign that you're biting off too much in terms of scope.
I also think it's deeply problematic that you don't seem to have shaped the proposal based on the expressed needs of people who have tried to use the current system and failed, and that you're seemingly ignoring the use case of all the many different kinds of contributors by focusing a comprehensive restructure solely for new contributors. When we make something like Echo, we're doing it first and foremost to attract new people, but we can't get away with ignoring the needs of existing users.
In general, I don't think you've fully considered how the current set up might serve our needs with less heavy-handed changes than migrating to Semantic MediaWiki, and I'm wary of supporting a restructuring of documentation systems I depend of every day based on a grand plan of any kind.
I'd like to add a +1 to Ori's request to trial the project in a much more minimal way, show some results, and then expand from there. If you can show what you're doing is working to bring in new contributors without requiring we rearchitect our entire system from the ground up on top of Semantic MediaWiki, then any change is a much easier pill to swallow.
Steven
On Wed, Apr 3, 2013 at 5:01 PM, Steven Walling steven.walling@gmail.comwrote:
Quim, I think even this first iteration is problematic on a bunch of fronts. 3 months as a first iteration to build several major features as the basic proof of concept should be a sign that you're biting off too much in terms of scope.
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.
I also think it's deeply problematic that you don't seem to have shaped the proposal based on the expressed needs of people who have tried to use the current system and failed, and that you're seemingly ignoring the use case of all the many different kinds of contributors by focusing a comprehensive restructure solely for new contributors. When we make something like Echo, we're doing it first and foremost to attract new people, but we can't get away with ignoring the needs of existing users.
We have a current system?
In general, I don't think you've fully considered how the current set up might serve our needs with less heavy-handed changes than migrating to Semantic MediaWiki, and I'm wary of supporting a restructuring of documentation systems I depend of every day based on a grand plan of any kind.
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 2:25 PM, Ryan Lane rlane32@gmail.com wrote:
On Wed, Apr 3, 2013 at 5:01 PM, Steven Walling <steven.walling@gmail.com
wrote:
Quim, I think even this first iteration is problematic on a bunch of fronts. 3 months as a first iteration to build several major features as the basic proof of concept should be a sign that you're biting off too
much
in terms of scope.
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.
I also think it's deeply problematic that you don't seem to have shaped
the
proposal based on the expressed needs of people who have tried to use the current system and failed, and that you're seemingly ignoring the use
case
of all the many different kinds of contributors by focusing a
comprehensive
restructure solely for new contributors. When we make something like
Echo,
we're doing it first and foremost to attract new people, but we can't get away with ignoring the needs of existing users.
We have a current system?
In general, I don't think you've fully considered how the current set up might serve our needs with less heavy-handed changes than migrating to Semantic MediaWiki, and I'm wary of supporting a restructuring of documentation systems I depend of every day based on a grand plan of any kind.
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
Let me put it a simpler way: I don't support moving to Semantic MediaWiki, which to me as user seems like a somewhat arcane and bloated piece of software that will require me and lots of people to relearn how we write documentation and project tracking, unless you can show why the changes you want to make are A) necessary B) require SMW to accomplish them. Demonstrating that the high level structure proposed will work before making the more drastic change seems like a good way to convince everyone that what's being proposed is the right path toward a better wiki for all.
Steven
On Wed, Apr 3, 2013 at 5:31 PM, Steven Walling steven.walling@gmail.comwrote:
Let me put it a simpler way: I don't support moving to Semantic MediaWiki, which to me as user seems like a somewhat arcane and bloated piece of software that will require me and lots of people to relearn how we write documentation and project tracking, unless you can show why the changes you want to make are A) necessary B) require SMW to accomplish them. Demonstrating that the high level structure proposed will work before making the more drastic change seems like a good way to convince everyone that what's being proposed is the right path toward a better wiki for all.
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 2:59 PM, Ryan Lane rlane32@gmail.com wrote:
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.
Yes, and that sounds like an advantage for people like Quim, whose job is to create structures for other people to use. What I'm saying, as someone who is living with our current totally imperfect system of documenting software and projects on a day-to-day basis, is that I don't see what the advantages are, and that a redesign and a migration needs to take in to account everyone's needs more, not just roles like Quim's and the new contributors he is admirably working to attract. The best way to approach a project like this is not to propose an up-front migration of an entire wiki to a new piece of software, just to prototype a few new features.
Steven
On Wed, Apr 3, 2013 at 6:06 PM, Steven Walling steven.walling@gmail.comwrote:
On Wed, Apr 3, 2013 at 2:59 PM, Ryan Lane rlane32@gmail.com wrote:
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.
Yes, and that sounds like an advantage for people like Quim, whose job is to create structures for other people to use. What I'm saying, as someone who is living with our current totally imperfect system of documenting software and projects on a day-to-day basis, is that I don't see what the advantages are, and that a redesign and a migration needs to take in to account everyone's needs more, not just roles like Quim's and the new contributors he is admirably working to attract. The best way to approach a project like this is not to propose an up-front migration of an entire wiki to a new piece of software, just to prototype a few new features.
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:12 PM, Ryan Lane rlane32@gmail.com 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.
Thanks for the clarification. Sorry to confuse the discussion on that point.
Steven
On Wed, Apr 3, 2013 at 3:06 PM, Steven Walling steven.walling@gmail.com wrote:
The best way to approach a project like this is not to propose an up-front migration of an entire wiki to a new piece of software, just to prototype a few new features.
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 Thu, 04 Apr 2013 00:10:38 -0700, Erik Moeller erik@wikimedia.org 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.
Yeah. It seems like some are suggesting that some of these docs should be moved to wikitech because they would work better if SMW is available. While at the same time suggesting that not all the docs would be moved to wikitech. Which quite frankly stinks of a conflict to me. Because I can see a lot of stuff on MW.org that would be better with SMW and would fall under the banner of things that are suggested would stay on MW.org.
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).
+1
More things fit under the MediaWiki (and related) umbrella than many here would admit.
I can understand Labs/Wikitech being another wiki for auth purposes. Like bugzilla uses another auth.
But beyond that I don't like the idea of it being used to split the documentation of related things even more making it harder to find. It was hard enough eliminating the split of MediaWiki related documentation and projects onto Meta. And it STILL is. Wikidata is actually documenting a great deal of wikidata stuff including a lot of ContentHandler stuff on Meta instead of MW.org. And only putting small documentation on MW.org with almost no reference at all to the Meta pages where the original design ideas planned things.
And honestly. It would be kind of nice if we could link LDAP indirectly to MW accounts. And make it easy to point MW developers on MW.org to a special page on MW.org to setup the credentials they use to log into Gerrit to commit and comment on core.
On 04/04/2013 12:10 AM, Erik Moeller wrote:
If the migration is merited, it is likely merited irrespective of whether we use SocialProfile, LQT, SMW, SMF, etc.
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.
On 04/04/2013 01:45 AM, Quim Gil wrote:
As far as I can see it is impossible to solve the puzzle without changing something and upsetting someone.
Well, no. There is always a possibility.
We can detach the Wikitech contributors prototype development from any content migration and leave mediawiki.org undisrupted during this first phase.
Wikitech has the basic software we need to build a prototype quicker and easier. Life in mediawiki.org would continue as it is. Everybody would be welcome to join the experiment but nobody would be forced to.
If/when the prototype is ready we can discuss about next steps with a better common understanding.
http://www.mediawiki.org/wiki/Requests_for_comment/Wikitech_contributors#Fir... has been edited accordingly.
On Thu, Apr 4, 2013 at 11:21 PM, Quim Gil qgil@wikimedia.org wrote:
Well, no. There is always a possibility.
We can detach the Wikitech contributors prototype development from any content migration and leave mediawiki.org undisrupted during this first phase.
Wikitech has the basic software we need to build a prototype quicker and easier. Life in mediawiki.org would continue as it is. Everybody would be welcome to join the experiment but nobody would be forced to.
If/when the prototype is ready we can discuss about next steps with a better common understanding.
http://www.mediawiki.org/wiki/**Requests_for_comment/Wikitech_** contributors#First_phasehttp://www.mediawiki.org/wiki/Requests_for_comment/Wikitech_contributors#First_phasehas been edited accordingly.
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 01:25 PM, Steven Walling wrote:
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.
Thank you very much! All the input received this week has been very useful to bring the proposal to a new level.
CHANGES
This will be an experiment on a side, not touching mediawiki.org. * No content migration. * No change in current workflows.
We are flexible with the development priorities. * The sequence at http://www.mediawiki.org/wiki/Requests_for_comment/Wikitech_contributors#Dev... is flexible. * Speak up! (in the discussion page, please)
Prototyping one small feature at a time. * Defining the problems we want to solve beforehand. * Evaluating the results before building more features on top.
Community evaluation based on results and lessons learned. * This experiment will propose changes to mediawiki.org only if/when clearly positive results can be demonstrated.
Hopefully this addresses the majority of concerns.
I'm also glad to see that the discussion is moving onto details at http://www.mediawiki.org/wiki/Talk:Requests_for_comment/Wikitech_contributor...
PS: Let me also say something. Even if the taste of this thread has been mostly negative, the individual feedback gathered from many people in the past weeks has been very different. Many have welcomed the idea and asked how to help. Some have been cautious, but curious and willing to see the proposal moving forward. Steven's quote at the top of this email made my day. :)
On 04/05/2013 03:19 PM, Quim Gil wrote:
Thank you very much! All the input received this week has been very useful to bring the proposal to a new level.
CHANGES
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.
Shall we talk here or on the discussion page?
On Tue, Apr 9, 2013 at 9:09 PM, Quim Gil qgil@wikimedia.org wrote:
On 04/05/2013 03:19 PM, Quim Gil wrote:
Thank you very much! All the input received this week has been very useful to bring the proposal to a new level.
CHANGES
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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 04/09/2013 10:42 AM, Yury Katkov wrote:
Shall we talk here or on the discussion page?
http://www.mediawiki.org/wiki/Project_talk:New_contributors please, as you already did. :)
Thanks!
Erik Moeller wrote:
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.
:D
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.
Yes, this. All of this.
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.
Before too much gets moved or migrated (for a second time, in some cases, as Daniel F. points out... some of this content was already moved from Meta-Wiki to MediaWiki.org), I'd like to see more thought put into where everything should end up. Moves/migrations are disruptive and the resulting mess may be worse than keeping everything where it is for now.
MZMcBride
Hey,
I don't support moving to Semantic MediaWiki,
... will require me and lots of people to relearn how we write documentation and project tracking, unless you can show why the changes you want to make are A) necessary B) require SMW to accomplish them.
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. --
On Wed, Apr 3, 2013 at 3:48 PM, Jeroen De Dauw jeroendedauw@gmail.comwrote:
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.
Okay let's assume nothing changes in the workflow for creating documentation. Which I don't. Even then, who's going to do the work of migrating all our project documentation over? Is it going to be Quim personally? Some unnamed contractor? Or are we just going to implement the new system but not migrate any existing project documentation?
Steven
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_consolidatio... accordingly.
On 04/03/2013 03:51 PM, Steven Walling wrote:
who's going to do the work of migrating all our project documentation over?
guillom, myself and whoever else wants to help.
http://www.mediawiki.org/wiki/Technical_communications/Dev_wiki_consolidatio...
I think we should consolidate wikitech and mediawiki. If wikipedia.org can fit all the world's knowledge, how come we can't fit all our technical know-how on one site? The fragmentation is unnecessary and arbitrary, it confuses most newcomers and those not paying attention to the "proper separation" between them.
The site should highlight and share the technology platform used at Wikimedia Foundation. *We need a site for everyone to look at, participate in, and replicate our technology.* Replication could be anything from the most basic MW installation to a complete replica of our cluster.
If we are not happy with the URL, lets come up with another one, or decide that wikitech is the preferred name, and redirect everything there. The main page would have mediawiki docs, labs, server info and stats, hackathons, apis, RFCs, and everything else related. Any non-wiki information like server health could be sub-domain of this site, possibly with extra permissions. Lets create and share a knowledge platform, not just software.
</end-rant> :)
On Thu, Apr 4, 2013 at 3:24 AM, Quim Gil qgil@wikimedia.org wrote:
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_consolidation#Proposed_**solutionhttp://www.mediawiki.org/wiki/Technical_communications/Dev_wiki_consolidation#Proposed_solutionaccordingly.
On 04/03/2013 03:51 PM, Steven Walling wrote:
who's going to do the work of migrating all our project documentation over?
guillom, myself and whoever else wants to help.
http://www.mediawiki.org/wiki/**Technical_communications/Dev_** wiki_consolidation#Stepshttp://www.mediawiki.org/wiki/Technical_communications/Dev_wiki_consolidation#Steps
-- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/**User:Qgilhttp://www.mediawiki.org/wiki/User:Qgil
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
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 erik@wikimedia.org wrote:
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.
On Thu, Apr 4, 2013 at 8:58 AM, Yuri Astrakhan yastrakhan@wikimedia.org wrote:
If we are not happy with the URL, lets come up with another one, or decide that wikitech is the preferred name, and redirect everything there.
It is not surprising that long term contributors with advanced wiki editing skills and familiar with the key people and corners of our community don't see a big need for change. Well, this is part of the problem.
Yes, Gerrit and Bugzilla have issues. This proposal focuses on the potential contributors that are not even getting there.
On 04/03/2013 02:01 PM, Steven Walling wrote: > I'd like to add a +1 to Ori's request to trial the project in a much more
minimal way, show some results, and then expand from there.
What first iteration would you propose, then?
As I see it, the current proposal is already taking shortcuts in order to have fast iterations. 3 months doesn't mean you don't relese new features in between.
Anything related with enabling Semantic Forms in specific types of pages can be done pretty fast at Wikitech, where those extensions are already installed. We could prototype that by analyzing a bit further notifications and nodes.
If you have a proposal for simpler steps I'm all ears.
rearchitect our entire system from the ground up
This proposal actually doesn't touch our current workflows. You can continue doing what you are doing. All the new features are optional. The worst that can happen is that you find in certain pages a soft-redirect, or a form instead of a {{template}}.
This is *not* about enabling SMW forms in all pages. Main namespace could be as MediaWiki pure as it is now.
On Wednesday, April 3, 2013 at 3:40 PM, Quim Gil wrote:
As I see it, the current proposal is already taking shortcuts in order to have fast iterations. 3 months doesn't mean you don't relese new features in between.
Anything related with enabling Semantic Forms in specific types of pages can be done pretty fast at Wikitech, where those extensions are already installed. We could prototype that by analyzing a bit further notifications and nodes.
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
On 04/03/2013 08:27 PM, Ori Livneh wrote:
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.
Ok, fair enough.
I will have this in mind in future edits to the proposal. Help defining data points is welcome at
http://www.mediawiki.org/wiki/Talk:Requests_for_comment/Wikitech_contributor...
Hi,
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.
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
-- Ori Livneh
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Ori Livneh wrote:
The core of MediaWiki is in my mind still radical and exciting: you make or find a page, click edit, and just type into it.
This feels like a hyper-idealized version of MediaWiki.
Describe the page creation process in WordPress and then describe the page creation process in MediaWiki. The MediaWiki process is three times as long and includes three times more caveats.
Now describe the category addition or removal process in WordPress and then describe the category addition or removal process in MediaWiki. Again, the MediaWiki process is three times as long and includes three times more caveats.
I realize your broader point was about the radical nature of the wiki (and Wikipedia and other sites are a living testament to this idea), but to look at MediaWiki and consider it good design is pretty insane, in my opinion. No visual editor, no input validation, almost no user interface when editing other than a terrifying textarea, no clear paths for how to add a page or a category or anything else.
MZMcBride
On Wed, Apr 3, 2013 at 9:06 AM, MZMcBride z@mzmcbride.com wrote:
Describe the page creation process in WordPress and then describe the page creation process in MediaWiki. The MediaWiki process is three times as long and includes three times more caveats.
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@gmail.com
Tyler Romeo 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"?
Sure, that's easy enough to explain: page creation suggests that the page does not yet exist. So you'll never get past the "find a page" step. ;-)
Ori correctly said "make or find a page." The problem is that the page creation process is completely unintuitive. The general bug is https://bugzilla.wikimedia.org/show_bug.cgi?id=27311#c0, if you're interested.
Tangential to the unintuitive page creation process is the editor itself, which surely we can all agree is difficult, if not impossible, for many, many users to use.
Once you know how MediaWiki works, it's pretty easy to create or edit a page, of course. But getting to that point can be painfully difficult.
MZMcBride
Hi, about Wikitech / mediawiki.org check
http://www.mediawiki.org/wiki/Technical_communications/Dev_wiki_consolidatio...
On 04/03/2013 12:30 AM, Ori Livneh wrote:
That seems wrong. Of the two, MediaWiki.org is clearly the more successful wiki.
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@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.
On 04/03/2013 04:19 PM, Quim Gil wrote:
Sure, but following this argument we could just have dev.wikipedia.org, right?
All of the wikitech, wikimediafoundation, outrech and other wikis together have fewer articles than the English Wikipedia. All could fit on meta.wikimedia.org.
Unfortunately the urge to "change" and make your own footprint in history is so much stronger than to actually organize knowledge and keep things small.
The idea to invent a new name (Wikimedia) in 2003 was a mistake, as everybody in outreach can testify. So many hours have been wasted trying to explain that there is a difference between P and M. I think we should keep the door open for the event that the next CEO (after Sue) might want to rename it to Wikipedia Foundation. Dev.wikipedia.org or (better) meta.wikipedia.org would be better than "wikitech". So much of statistics and analytics is not strictly "tech", but all of it, including outreach, is "meta".
On 04/06/2013 12:38 PM, Lars Aronsson wrote:
The idea to invent a new name (Wikimedia) in 2003 was a mistake, as everybody in outreach can testify.
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
About the virtues of MediaWiki software.
On 04/03/2013 12:30 AM, Ori Livneh wrote:
The core of MediaWiki is in my mind still radical and exciting: you make or find a page, click edit, and just type into it.
I agree, and perhaps this is one of the reasons why we are still here and not at [your preferred CMS].
http://www.mediawiki.org/wiki/Requests_for_comment/Wikitech_contributors doesn't remove any MediaWiki feature: all are there. Contributors can create and edit regular wiki pages as always.
The use of Semantic Forms is proposed to solve specific cases where a form and a predefined page structure is useful: user profiles, projects, tasks, events and nodes. And even all these specific types of pages include the beloved bug textarea taking the usual functionality.
For an example look http://www.mediawiki.org/wiki/File:Wikitech_node_concept.jpg
The first central block "Node: Lua" is your old free-form wiki page. The rest would be aggregated automatically thanks to the structured data introduced elsewhere by a bunch of users, collaboratively.
Yes, you could do all that templating and categorization manually... But it requires a lot more editor knowledge and discipline in exchange of a higher risk of driving people away and breaking things. So yes, I believe that using forms for specific types of pages is a good idea.
On 04/03/2013 03:30 AM, Ori Livneh wrote:
That seems wrong. Of the two, MediaWiki.org is clearly the more successful wiki. It is larger by all measures, and draws a wide pool of active contributors.
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.
Semantic this-and-that and ontologies of categories entails putting up rails everywhere and signs with arrows on them indicating which way you should go. That approach will inevitably end up reflecting a narrow, inflexible view of what a wiki is and what you do with it.
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 03/04/13 20:48, Matthew Flaschen wrote:
On 04/03/2013 03:30 AM, Ori Livneh wrote:
That seems wrong. Of the two, MediaWiki.org is clearly the more successful wiki. It is larger by all measures, and draws a wide pool of active contributors.
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.
I know some of WMF-specific stuff would still be useful to others trying to do similar - things like server setup, installation issues, configuration and good practices and whatnot comes to mind. Having examples of what others have done - mostly Wikimedia and ShoutWiki in my case - proved invaluable when I was setting up my own wikifamily-like thing, at least, but they weren't exactly easy to find.
On Wed, Apr 3, 2013 at 5:19 PM, Isarra Yos zhorishna@gmail.com wrote:
On 03/04/13 20:48, Matthew Flaschen wrote:
On 04/03/2013 03:30 AM, Ori Livneh wrote:
That seems wrong. Of the two, MediaWiki.org is clearly the more successful wiki. It is larger by all measures, and draws a wide pool of active contributors.
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.
I know some of WMF-specific stuff would still be useful to others trying to do similar - things like server setup, installation issues, configuration and good practices and whatnot comes to mind. Having examples of what others have done - mostly Wikimedia and ShoutWiki in my case - proved invaluable when I was setting up my own wikifamily-like thing, at least, but they weren't exactly easy to find.
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 03/04/13 22:26, Ryan Lane wrote:
On Wed, Apr 3, 2013 at 5:19 PM, Isarra Yos zhorishna@gmail.com wrote:
On 03/04/13 20:48, Matthew Flaschen wrote:
On 04/03/2013 03:30 AM, Ori Livneh wrote:
That seems wrong. Of the two, MediaWiki.org is clearly the more successful wiki. It is larger by all measures, and draws a wide pool of active contributors.
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.
I know some of WMF-specific stuff would still be useful to others trying to do similar - things like server setup, installation issues, configuration and good practices and whatnot comes to mind. Having examples of what others have done - mostly Wikimedia and ShoutWiki in my case - proved invaluable when I was setting up my own wikifamily-like thing, at least, but they weren't exactly easy to find.
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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
That was my point, actually - I had to go out and find it elsewhere as none of what I used was on mw.org, but it would have been nice if it were.
Hi everyone!
I think that there are two categories of developers now: 1) Wikimedia developers deal with Wikimedia tasks of running Wikipedia and all other projects 2) Independent developers which use MediaWiki for their needs. I think that not much of us even know that wikitech website exist. :)
IMO stuff related to inner projects of Wikimedia foundation should be located on wikitech. Manuals that are related to MediaWiki as a software and its extensions should live on MediaWiki.org. No Wikimedia-specific materials here.
----- Yury Katkov, WikiVote
On Tue, Apr 2, 2013 at 4:45 PM, Quim Gil qgil@wikimedia.org wrote:
I have been drafting a proposal to attract new contributors, help them settle in, and connect them to interesting tasks. It turns out that many of these problems are not unique to new contributors. We suffer them as well and we are just used to them.
The proposal has evolved into a deeper restructuring of our community spaces. We're still drafting it, but a round of wider feedback is welcome before opening the official RFC at
https://www.mediawiki.org/**wiki/Requests_for_comment/** Wikitech_contributorshttps://www.mediawiki.org/wiki/Requests_for_comment/Wikitech_contributors
In summary:
- wikitech.wikimedia.org would become the one and only site for our open
source software contributors, powered by semantic software and an ontology of categories shared across wiki pages, Bugzilla and hopefully Gerrit.
- Semantic user profiles would identify interests, project membership and
preferences so users could get notifications about specific topics.
- Nodes would automatically structure links to the key information about a
specific topic: wiki pages, events, news, projects, bug reports, Gerrit changesets, related contributors, and people interested.
- All project teams, whoever is in them, would have a standard way to
report goals, members, tasks and updates.
The proposal includes a draft plan for a first iteration, including contracting out some software development and redesigning part of wikitech and mediawiki.org.
Your feedback is welcome at the discussion page. I will be consolidating there any feedback received here or through other channels. The official RFC should follow pretty soon, maybe next week.
-- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/**User:Qgilhttp://www.mediawiki.org/wiki/User:Qgil
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 04/03/2013 09:48 AM, Yury Katkov wrote:
IMO stuff related to inner projects of Wikimedia foundation should be located on wikitech. Manuals that are related to MediaWiki as a software and its extensions should live on MediaWiki.org. No Wikimedia-specific materials here.
This seems like a simple, and clearly delineated distinction. Even I was wondering why the Tool Labs (which is clearly Wikimedia-centric, and not all that directly Mediawiki-related) had its documentation living on mw.
-- Marc
On Wed, Apr 3, 2013 at 10:33 AM, Marc A. Pelletier marc@uberbox.org wrote:
On 04/03/2013 09:48 AM, Yury Katkov wrote:
IMO stuff related to inner projects of Wikimedia foundation should be located on wikitech. Manuals that are related to MediaWiki as a software and its extensions should live on MediaWiki.org. No Wikimedia-specific materials here.
This seems like a simple, and clearly delineated distinction. Even I was wondering why the Tool Labs (which is clearly Wikimedia-centric, and not all that directly Mediawiki-related) had its documentation living on mw.
I totally support this.
-Chad
On 04/03/2013 06:48 AM, Yury Katkov wrote:
Hi everyone!
I think that there are two categories of developers now:
- Wikimedia developers deal with Wikimedia tasks of running Wikipedia and
all other projects 2) Independent developers which use MediaWiki for their needs. I think that not much of us even know that wikitech website exist. :)
IMO stuff related to inner projects of Wikimedia foundation should be located on wikitech. Manuals that are related to MediaWiki as a software and its extensions should live on MediaWiki.org. No Wikimedia-specific materials here.
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. Do as Yuri says and 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.
This would hopefully satisfy as well the feedback received at http://www.mediawiki.org/wiki/Talk:Technical_communications/Dev_wiki_consoli...
If there is agreement about this then I can just edit accordingly
http://www.mediawiki.org/wiki/Technical_communications/Dev_wiki_consolidatio...
Le 03/04/13 15:48, Yury Katkov a écrit :
IMO stuff related to inner projects of Wikimedia foundation should be located on wikitech. Manuals that are related to MediaWiki as a software and its extensions should live on MediaWiki.org. No Wikimedia-specific materials here.
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
On 04/03/2013 11:26 AM, Antoine Musso wrote:
Le 03/04/13 15:48, Yury Katkov a écrit :
IMO stuff related to inner projects of Wikimedia foundation should be located on wikitech. Manuals that are related to MediaWiki as a software and its extensions should live on MediaWiki.org. No Wikimedia-specific materials here.
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
Do we have templates yet for marking stuff to be moved MW => Wikitech and vice versa?
Matt Flaschen
On 03/04/13 14:48, Yury Katkov wrote:
Hi everyone!
I think that there are two categories of developers now:
- Wikimedia developers deal with Wikimedia tasks of running Wikipedia and
all other projects 2) Independent developers which use MediaWiki for their needs. I think that not much of us even know that wikitech website exist. :)
IMO stuff related to inner projects of Wikimedia foundation should be located on wikitech. Manuals that are related to MediaWiki as a software and its extensions should live on MediaWiki.org. No Wikimedia-specific materials here.
Yury Katkov, WikiVote
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.
On Tue, Apr 02, 2013 at 05:45:58AM -0700, Quim Gil wrote:
- wikitech.wikimedia.org would become the one and only site for our
open source software contributors, powered by semantic software and an ontology of categories shared across wiki pages, Bugzilla and hopefully Gerrit.
This is excellent. We recently had the merger of labsconsole and wikitech and this is a great (and ambitious!) next step. Kudos.
One thing that I'd like to see though -and which I think is central to the success of your proposal- would be allocation of more engineering resources for wikitech. Ryan and Andrew are doing an excellent job by holding the fort almost by themselves, but if we're to do this, I'd like to see more of an effort and commitment by other people/teams.
Having the same person do UI, sole maintainership of OpenStack & authentication MW extensions and operations/upgrade for the wiki (among a million other things), just doesn't cut it. Both the labsconsole and wikitech experiences had smaller or larger several issues and while the recent efforts as part of the merger alleviated some of them, we still have a long way to go. For example, I think some of OSM pages' in particular could use some help from UX experts -- no offence to Ryan, I'm sure I'd do worse; but UX is in neither of our job descriptions.
Incorporating wikitech to the regular platform processes (deployments & version updates, configs etc.) would also be needed if we want to do a reasonable job and provide contributors with a maintained platform. From lagging MediaWiki versions to IPv6, wikitech is just not on the same level of support as the rest of the cluster right now.
Regards, Faidon
wikitech-l@lists.wikimedia.org