MediaWiki Usage Report 2015/What barriers, if any, do you think exist to participation in the MediaWiki community? What can we do to help?

Connection to WMF, Wikipedia > community of 3^rd party users

• The underlying perception that MediaWiki's focus should be on Wikipedia. MediaWiki is bigger than Wikipedia and everyone needs to accept that fact. It is critical that the community address the needs of the majority, even if that means working on features that aren't relevant for Wikipedia. MediaWiki and Wikipedia can diverge and still thrive together. The more that the WMF supports "3rd-party users", the more those 3rd-party users will support the WMF.
• I think MediaWiki is not attractive to either enterprise users (lack of proper permission controls is the main reason) or freelancers (great documentation and a nice admin interface are missing the most) and that limits involvement from developers outside the Wikimedia universe and in the end endangers self-sustainability. I would love to see a separate MediaWiki organization, funded by the Foundation for a few years with the goal of becoming self-sustainable, that tries to make MediaWiki attractive to a wider demographic of developers and into more of a framework than a CRM (Drupal is a good role model).
• WMF development feels much like a closed shop
• the preception is that WMF is interested only in MediaWiki for the WMF and not for outsiders

Not (good) enough documentation > improve documentation

• 2) Documentation - it's hard to start out because documentation is the last thing a developer wants to work on. So it is often outdated or incomplete.Documentation is either absent or incredibly verbose and detailed as a giant wall of text.
• Documentation, documentation, documentation. But maybe that's just me.
• There is a huge barrier of entry, for users and admins alike. MediaWiki is "programmed" in content pages (templates, but also advanced HTML layouts, queries, and forms), but this programming is left almost entirely to the user. It's a developers' system with mostly developers' documentation. A starting point might be to create tutorials that focus on a functionality that an actual user might want in her or his wiki ("mobile-friendly portal page", "twitter feed box", "MW-based news feed", "multi-language wiki", "event calendar", "in-page search form", ...). Right now, most of our documentation is technology driven, not use-case-driven.
• Poor documentation, which is either outdated or entirely missing.

Focus on development > focus on use cases

• Way too developer/tech focused. There are many people who don't (or won't) spend the time trying to figure out MediaWiki with it's crazy dependencies and issues - composer, extensions are ill-supported, updates break things, newest (and best) editor requires more technical debt.
• Provide easy to understand use cases that show more than classical wiki tasks - MediaWiki is much more useful and powerful than most people know.

Versioning

• Due to the difficulty in keeping versions and extensions up-to-date, our wiki is always lagging behind in updates. That is why I am always using older versions and unable to contribute bug reports.

People try and want to help, but are not always sure, how they can.

Introduce, include newbies, encourage productivity – user/devs, Centralizing community

• 3) Intimidation - there are many strong-minded developers in the community and newcomers can easily be discouraged from contributing.
• Not clear how to get newbies like myself going productively at hackathons
• Ease the entrance – at the beginning it's hard to find out: How can I help – without stepping on somebody's toes? How can I help without being the 100% expert yet? Where is my help needed and wished?
• getting in is a rather tedious process. people already in the community knw each other and - most of the time - don't see the necessity to include new people.
• Getting into mediawiki extension programming was really hard. Often the documentation was not detailed enough. Most of the things I needed to know I had to reverse engineer. One of the reasons was also that in many parts of mediawiki code there is no or only bad documentation. Most of the comments don't explain what it is used to do but rather repeat the function name.
• I feel like a bit of an outsider, and don't know where to participate... Discussion pages, bug reports, IRC, etc. Have sort of given up on finding 'a place' I guess.
• If anything, perhaps centralizing the community better. It feels today like there's so many community corners, such as IRC channels, mailing lists, etc. that the average person doesn't know where to begin.
• In honesty, the community is fairly open, possibly even more so that the Wikipedia community at large. However, for newcomers, the organisation and sprawl within the mediawiki project is a little disconcerting. It has improved greatly in recent times though
• Knowing good ways to help. I know there are resources, but they could be more prominent.
• MediaWiki development is focused on Wikipedia, which ignores the needs of thousands other users and hundreds other use cases.
• Mediawikifoundation is revolving around it's own agenda which is based on the experience with millions of people using the wikipedia sites. This is a great thing and has made a lot of success possible. Now for enterprise usage some of the basic assumptions e.g. about security and non-public wikis are in the way of needed progress for enterprise use.
• which media to use ? what kind of contribution is wanted ?
• Not easy to find who to contact or status of the software development.
• Need a beginners group or new to mediwiki group.
• newbies should be taken seriously, sometimes I miss that,
• No direct contact, slow answer or no answer rate in support chats, no people guiding you at the beginning.
• Not regularly basic technical workshops to get involce in mediawiki community.
• Outside of the software, it can hard to be new to any group, so that perceived barrier is probably the largest for newcomers. I know it was for me and my team. Especially since we come from a community building background, as opposed to a coding or computing background. That said, now that I feel part of the community, I feel the community is warm and welcoming.
• Tough for beginners to break-in. Always the feedback we get from contributors at our site. And as an admin of a wiki, it is hard learning how run the site properly. Even our IT staff has a difficult time administering the wiki.
• Use the same medium as users, wiki and IRC. Avoid Google docs.
• There are a lot of communication channels
• Some of us are just too busy. I think that good calendars and organization and plans can help people like me to be better players in the space because it's factored into my plans.
• The only way I'm really connected to the "community" is via the mailing list, but I don't find it a very engaging way to be connected. I get the digest and usually just scan the subject lines. Not sure what tools would increase my participation - possibly Discourse style forums.
• Probably too many know-everything-people around, no easy path to integration of newbies
• Maybe more and frequent local meetings

Development

• easier pushing existing very old extensions to git/gerrit
• Easy to post an extension, and never get any feedback from others. No way to see who has downloaded or used it; no feedback from the general community.
• Faster, more active code review.
• From a developer's perspective, some patches take an extremely long time (I've had patches go over a year) to be reviewed.
• Nobody cares about things that are important to us. We have to do everything ourselves, but attempts to get code merged upstream languish or outright fail.
• Publishing an extension in a good way requires a rather complex setup. Can we make that easier?
• Resources. We have a couple custom extensions that work for us, but it is difficult for us to actually release them open source - test them against various versions, strip out idiosyncratic company-specific features, and make useful for a wider audience. We do intend to release a couple of these extensions at some point though.
• The complexity (compared to e.g. Github) of contributing code.
• The GIT / Labs process is very confusing and there is conflicting information in the documentation. I started the process 3 different times before finally completing it, and I had to ask for support as my account didn't get created properly.
• Software development seems highly tied to Wikipedia. We would like to contribute more to software development but there is no software grants available for us to improve core and extensions to the project. https://meta.wikimedia.org/wiki/Grants:PEG/Offline_MediaWiki_search_for_NASA_and_Medicine Lots of community development grants but the software has so much potential it would be good to allow the disparate groups to be brought into the fold (ie. SemanticMediawWiki)
• Some sort of incentives for keeping up and participating. I'm not talking financial, I just often fail to see the benefits of upgrading and/or participating. It would be good to see some tutorials for doing things like upgrading old tag-style extensions to first-class parser functions, for example. (I've started to upgrade one extension about three times, and get blocked on "what's next...")

Awareness, spread the word.

• "Awareness. It is amazing how many people still don't know about this great tool-set"
• "Most of the local people to whom I have mentioned Semantic Mediawiki are not familiar with it, so I continue to mention it whenever I think that it might be helpful."

Continuity

• "developer tools are changing all the time"

Concise Information about the most important

• "Difficulty receiving information of what really matters and is interesting; it's basically all or nothing."
• "Ways to provide small doses of feedback (votes, etc) without having to subscribe to or follow noisy channels."
• " It's complex as hell, both on the community level and the development level"

Enterprise issues: Competition

• "Many companies still want to try the SharePoint Wiki offering since they use SharePoint so readily - IT departments in corporations are often reluctant to support MediaWiki"

Technical obtacles: Composer

• "One of my concerns is the use of Composer and how it affects the newbies. There are a lot of users who are tech savvy enough to grab MW and install it on the shared server. Yes, I know Composer has a lot of benefits in maintaining and deploying libraries. I worry though you're limiting new users to a smaller group. "

Complexity of the software

• "Steep learning curve, some devs have good answers very fast most of the time, so its most of the time already answered, if there is a question that one can answer."
• "steep technical learning curve"
• "the only barrier I see is the user has a hard time interpreting the language of the developers. Even after reading Yoran's book for Mediawiki and doing a ton of research I find myself scratching my head about many things within Mediawiki. "
• "too difficult to understand"

Responsibility

• "See above. There is basically nobody (dedicated person) listening if you enter via mediawiki.org. I just depends if there is a good WMF product manager around (this group is by far the worst), an involved person on the support page or a good extension maintainer if you want to get heard. To cut it short: There is nobody taking care of the unanswered rest, i.e. someone who could give pointers to some directions."

Other

• "People already know a lot. I'm amazed at the nuances that get discussed on the mailing list."
• "perform surveys using SemForms not Google"
• I don't know - I love mediawiki, but I don't have the knowledge or time to participate in the broader community really.
• I don't know.
• I can't think of any major barriers to participation.
• I don't do PHP or JavaScript
• Learning PHP and MediaWiki PHP
• I've sent polite emails to a WMF developer and not received a response. Please respond to polite email queries.
• No idea.
• Thanks for doing this survey!
• None that I am aware of.
• None that I know of.
• Nothing as far as I know.
• We don't see barriers. It may be 'more appealing' however if modern skins (we use Chameleon as the standard skin for our solutions) are mainstream and MediaWiki use for business is promoted.
• that being said, I am very happy with Mediawiki and the movement. I am a donor as well.

Time

• time - no help possible
• Not enough time
• Sorry out of time
• Unfortunately, the main barriers that prevent my personal participation are my own constraints on time and other obligations. While I try to contribute to answering questions on the mailing lists from time to time, they usually get answered by someone more knowledgeable than me by the time I finally get around to them. I'm afraid there's not much I could offer in ways to improve participation at this time.

?

• Proxies: people I can provide feedback casually and they will consolidate / prioritize / do the right thing.
• English as lingua franca, WMF, usurpation of projects by single coders or two usually from WMF or affiliate staff.
• Enjoy the Friday sessions when I can attend.
• Making the internet accessible for all. But, it needs a lot of Self discipline to consider this!From zerO to herO is what I mean
• Nothing significant in the 'community' itself. However, since it is comprised largely of clever, young people, there is a subtle obstacle; viz - successful careers depend largely upon the necessity of (at least tacit) adherence to official narratives of the West's moral superiority, in its notions pf 'progress' and its dealings with the rest of the world; when in reality it is becoming - and probably by design of its a defacto masters - a veritable moral sewer. Wikispooks sits way outside such official narrative concensus. We are thus apt to be dimissed at tin-foil-hat-wearing conspiracy-loons
• plugin jungle to add user friendly uses as user_board, gift, contribution score.lot a people want a mini blog around their contributions, or just web-ify their mindings. maybe a mediawiki-diaspora mixed thing? http://wiki.funlab.fr/index.php/Sp%C3%A9cial:Version, http://wiki.funlab.fr/index.php/Funlab http://wiki.funlab.fr/index.php/Utilisateur:Tuxun
• There must be a friendly environment, better documentation (imo especially old docs from 8 years ago are a mess) and no one should be afraid of contributing :)