I'm happy to mention that the board has authorized the foundation to accept a significant grant, for which we just recently received the funds. This is a restricted grant specifically for use on a project to improve the MediaWiki software and the experience for new contributors. Not that this is a direct result of recent discussions here, plenty of people have mentioned the issue before, including Delphine as Ting points out. As you may know, grants take more than a day or two to put together, but it's relevant to mention anyway. I understand a press release with more details will be going out in the next day or so.
While grants with restrictions should be considered with care (one reason for the board to be involved), we've indicated for some time that this is an issue the foundation feels strongly about addressing. As a result, any hesitation was really more about the challenges involved in executing the project. I don't know just how far this will carry us, but since it focuses on the underlying software, I hope it will benefit more than just "80% of our projects" - even the ones that don't need help, or don't think they do. I encourage volunteers to get involved in supporting the effort as the project moves forward.
This grant is also from a source that has provided a smaller amount of funding before. It's gratifying when donors recognize the impact they are having and decide they want to add to it.
--Michael Snow
Hoi, This is great news, this makes me really happy. As I have been arguing before, the lack of usability prevents many people from contributing to wikis. Many of our projects are failing and, usability is a major factor in this. Combine this with a lack of localisation for many languages, a digital divide that prevents many demographies either by lack of infrastructure and/or lack of skills. The great thing about usability is, that this is the one place where it easiest for us to make a difference.
In the announcement it is said, that the experience for new contributors is to be improved by the usability improvements funded by this grant. UNICEF has done usability studies, giving newbies tasks to perform like creating new articles. They have many videos and I understand that they may be willing to share them with us for this effort. Based on their observations, developers at UNICEF have developed a set of extensions that have proven themselves in raising the collaboration of UNICEF wikis. These extensions are in the WMF SVN, they are being localised in Betawiki and they have been tested in the ExtensionTesting environment.
Marjon and Magnus have testified that MediaWiki is problematic for newbies everywhere. Our lack of usability is hurting us and we have a self selecting group of editors based on the ability in overcomming the problems of our environment. Many demographics are not well represented and this leads to bias and to the underrepresentation of the subjects these demographics have an interest in. In the majority of our projects we are not even able to raise a sustainable community.
With a significant grant received, it should be possible to create metrics that measure the success of the work that we are about to do. Just receiving the money and doing the things that seem to make sense does not cut it. In a different thread I stated that 80% of our projects are failing. With an improved usability, it should be possible to notice a difference. The localisation work at Betawiki has doubled the number of languages that provide a minimal support. Sadly we do not have any numbers how this has affected the projects in those languages.
As the WMF has accepted this money for a targeted grant, and as Michael indicates that the board feels strongly about this issue, I am lead to understand that usability has been made a priority in the further development of MediaWiki. Indeed improved usability will benefit more then 100% of the WMF projects, it will have a big impact on all the MediaWiki projects out there, the projects by educational organisations like Commonwealth of Learning, Kennisnet, the projects by hosting organisations like Wikia and Wikiation, the small organisations like my "housing community".
Given the investments in usability outside of the WMF already made, I do urge the WMF to learn from what has already been done and to incorporate the lessons learned, the software developed. I would love to see more cooperation in the further development of MediaWiki with the other stake holders in the MediaWiki software. Thanks, GerardM
2008/12/3 Michael Snow wikipedia@verizon.net
I'm happy to mention that the board has authorized the foundation to accept a significant grant, for which we just recently received the funds. This is a restricted grant specifically for use on a project to improve the MediaWiki software and the experience for new contributors. Not that this is a direct result of recent discussions here, plenty of people have mentioned the issue before, including Delphine as Ting points out. As you may know, grants take more than a day or two to put together, but it's relevant to mention anyway. I understand a press release with more details will be going out in the next day or so.
While grants with restrictions should be considered with care (one reason for the board to be involved), we've indicated for some time that this is an issue the foundation feels strongly about addressing. As a result, any hesitation was really more about the challenges involved in executing the project. I don't know just how far this will carry us, but since it focuses on the underlying software, I hope it will benefit more than just "80% of our projects" - even the ones that don't need help, or don't think they do. I encourage volunteers to get involved in supporting the effort as the project moves forward.
This grant is also from a source that has provided a smaller amount of funding before. It's gratifying when donors recognize the impact they are having and decide they want to add to it.
--Michael Snow
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
On Wed, Dec 3, 2008 at 2:02 AM, Michael Snow wikipedia@verizon.net wrote: [snip]
improve the MediaWiki software and the experience for new contributors. Not that this is a direct result of recent discussions here, plenty of people have mentioned the issue before, including Delphine as Ting
[snip]
Sadly most of the discussions on these lists run on without mention of the efforts that have come before, in this case see: http://en.wikipedia.or/wiki/Wikipedia:Article_wizard
When people discuss enhancements it seems that it is taboo to discuss the question of what happens when the communities reject these efforts.
Too often we blame technical issues as limiting factors for usability when with a little creativity a 90% solution is available without waiting for inflexible technical solutions which never seem to come. Unfortunately, interest, project politics, and other social factors are ready to stand in the way of progress even when there are no technical roadblocks at all.
That link should be http://en.wikipedia.org/wiki/Wikipedia:Article_wizard I presume
Finn R.
2008/12/3 Gregory Maxwell gmaxwell@gmail.com
On Wed, Dec 3, 2008 at 2:02 AM, Michael Snow wikipedia@verizon.net wrote: [snip]
improve the MediaWiki software and the experience for new contributors. Not that this is a direct result of recent discussions here, plenty of people have mentioned the issue before, including Delphine as Ting
[snip]
Sadly most of the discussions on these lists run on without mention of the efforts that have come before, in this case see: http://en.wikipedia.or/wiki/Wikipedia:Article_wizard
When people discuss enhancements it seems that it is taboo to discuss the question of what happens when the communities reject these efforts.
Too often we blame technical issues as limiting factors for usability when with a little creativity a 90% solution is available without waiting for inflexible technical solutions which never seem to come. Unfortunately, interest, project politics, and other social factors are ready to stand in the way of progress even when there are no technical roadblocks at all.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Hoi, I had a look. It is based on templates. What templates do wonderfully is create a proof of concept. When you have a look at the UNICEF implementation, you will learn that the same idea is implemented by them. On their wikis they do have templates for particular types of content. So I agree, it is a great idea.
When you mention the "taboo" of rejection by a community, I can tell you that this is one thing that I talk about quite often. Now rejection should be based on arguments and it is important to understand the arguments WHY things are proposed and the arguments WHY proposals are rejected. When people just vote, there is nothing that helps in understanding the reasons why, there is no handle on the argument that will help with preventing the negative effects of a proposal. When one community rejects a proposal, new functionality does not need to be rejected by other communities. Extensions do not need to be enabled. However, when Brion in his role as chief technical officer and architect of MediaWiki decides that somethig should go in regardless. This would be the case when functionality needs to be part of the MediaWiki core.
When you are talking about "inflexible" solutions, you have to appreciate that you are capable of creating the most wonderful templates. These same templates scare many people away. So where you see a wonderful template I find projects like the Neapolitan Wikipedia reject them because they scare people away (it does work for them). So you are completely correct that social issues play a part in accepting solutions. The solutions that come with templates are rejected by many just for comming as a template, will this prevent you from using them? Templates are great for proto typing, they are however a help and a hinder. If anything we need to find a way to overcome the problems people have with templates because they do provide value. Thanks, GerardM
2008/12/3 Gregory Maxwell gmaxwell@gmail.com
On Wed, Dec 3, 2008 at 2:02 AM, Michael Snow wikipedia@verizon.net wrote: [snip]
improve the MediaWiki software and the experience for new contributors. Not that this is a direct result of recent discussions here, plenty of people have mentioned the issue before, including Delphine as Ting
[snip]
Sadly most of the discussions on these lists run on without mention of the efforts that have come before, in this case see: http://en.wikipedia.or/wiki/Wikipedia:Article_wizard
When people discuss enhancements it seems that it is taboo to discuss the question of what happens when the communities reject these efforts.
Too often we blame technical issues as limiting factors for usability when with a little creativity a 90% solution is available without waiting for inflexible technical solutions which never seem to come. Unfortunately, interest, project politics, and other social factors are ready to stand in the way of progress even when there are no technical roadblocks at all.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
On Wed, Dec 3, 2008 at 4:58 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, I had a look. It is based on templates. What templates do wonderfully is create a proof of concept.
I agree. My concern is that we should not jump first into writing software unless a proof of concept is not possible. We will not get the software right the first time, fewer people have the skills needed to change the software, etc. The first priority is obtaining a good understanding of what works through prototyping, but we fail at that. The possibility of future software is used as an argument against any prototyping.
When you mention the "taboo" of rejection by a community, I can tell you that this is one thing that I talk about quite often. Now rejection should be based on arguments and it is important to understand the arguments WHY things are proposed and the arguments WHY proposals are rejected. When people just vote, there is nothing that helps in understanding the reasons why, there is no handle on the argument that will help with preventing the negative effects of a proposal.
English Wikipedia, as a high profile example, simply does not want to encourage new users to create articles. In fact, over time they have intentionally increased the barrier to create new articles: You now must have an account for 4 days and make 10 edits before you can create an article on EnWP. If you've made it that far without being blocked you probably do not need the wizard.
Arguments made include positions backed by solid fact such as "The overwhelming majority of contributions by inexperienced people are very low quality" as well as less factual but hard to argue against positions such as "We do not know what effect this may have, but it could be very bad, and we may never be able to turn it off".
I would like to think this class of problems is unique to English Wikipedia, but I've seen it to varying degrees in other communities which use super-majority as the decision criteria, and I suspect that it may be the fate of many projects as they mature.
When one community rejects a proposal, new functionality does not need to be rejected by other communities. Extensions do not need to be enabled.
This is true. But it's poor use of resources to churn out feature after feature that many communities will reject.
[snip]
When you are talking about "inflexible" solutions, you have to appreciate that you are capable of creating the most wonderful templates.
[snip]
I'm not wed to the concept of templates, and certainly not to their implementation today. If you search the lists you'll find cases of me ranting about "edit this page" bringing up two screens of template-gunk on many articles.
What I am strongly opposed to is our practice of inventing functionality in a near-vacuum and throwing it out as faite accomplis. Not only do I believe that you, me, and the other kind residents of this list are unqualified to produce perfect solutions to complex social-technical issue in a single pass, I believe no one is.
The questions for any new non-trivial functionality should be: (1) Can you prototype it or study it without software changes and learn more about what we really need? (2) Have you tried alternative solutions? (3) From your prototyping what evidence do you have for and against the proposed changes? (4) Is there a more minimal software change which would address this need in a generic manner and facilitate more learning and prototyping?
We ask none of these today. Instead, temporary solutions are widely rejected because some undefined software solution will be available "any day now", which either never comes, or when it does come is not activated because people believe that it fails to meet the requirements because no one took the effort to really understand and define the requirements.
Gregory Maxwell wrote:
On Wed, Dec 3, 2008 at 4:58 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, I had a look. It is based on templates. What templates do wonderfully is create a proof of concept.
I agree. My concern is that we should not jump first into writing software unless a proof of concept is not possible. We will not get the software right the first time, fewer people have the skills needed to change the software, etc.
I expect we all recognize that software is not the solution to every problem. As far as improving the learning experience for new contributors, I certainly hope this doesn't cause anyone to give up working on other avenues and tackling any cultural challenges that should be addressed.
The purpose of this grant, however, goes beyond just simplifying a particular process, so from that perspective it's not a question of whether software is the best way to do that. Rather, we're treating the MediaWiki software as a critical aspect of the overall environment for our projects, and one that can and should be improved. "Best-of-breed" it may be, but I think it's apparent that sometimes it hinders efforts that need help, so I consider it worthwhile to reduce the obstacles it introduces to our environment. Indeed we have not gotten it right the first time, which is why we have accepted this grant, as we keep trying to get it right.
The first priority is obtaining a good understanding of what works through prototyping, but we fail at that. The possibility of future software is used as an argument against any prototyping.
I believe that's the logical fallacy known as "argument from vaporware". Just because software might change how things work in the future doesn't mean we should avoid working on other improvements in the meantime. Unless we know that a specific feature is in the works and will conflict with the proposed solution, there's no reason to forbid experiments. Otherwise, I think I'd happily start nuking unsightly infobox markup on the theory that some future software can be counted on to automatically generate the information from article prose. It is just prototyping for the Semantic Web, after all.
--Michael Snow
Gregory Maxwell wrote:
On Wed, Dec 3, 2008 at 2:02 AM, Michael Snow wikipedia@verizon.net wrote: [snip]
improve the MediaWiki software and the experience for new contributors. Not that this is a direct result of recent discussions here, plenty of people have mentioned the issue before, including Delphine as Ting
[snip]
Sadly most of the discussions on these lists run on without mention of the efforts that have come before, in this case see: http://en.wikipedia.or/wiki/Wikipedia:Article_wizard
When people discuss enhancements it seems that it is taboo to discuss the question of what happens when the communities reject these efforts.
Too often we blame technical issues as limiting factors for usability when with a little creativity a 90% solution is available without waiting for inflexible technical solutions which never seem to come. Unfortunately, interest, project politics, and other social factors are ready to stand in the way of progress even when there are no technical roadblocks at all.
Note also that the Slovenian Wikipedia has an adaptation of this[1] that they link to from the message shown when creating a new article[2] (the second line of the message).
[1] http://sl.wikipedia.org/wiki/Wikipedija:Napi%C5%A1i_%C4%8Dlanek [2] http://sl.wikipedia.org/wiki/MediaWiki:Newarticletext
wikimedia-l@lists.wikimedia.org