hi
we have created our media wiki on our domain. we want to redirect user when they enter our domain on browser to another custom html page in mediawiki. for example if user enter our domain http://example.com they redirect to custom page.
thanks
Project talk:New contributors
Project:Support desk is the correct place to ask for help on issues related to operating MediaWiki.
We don't need to run any survey to be sure that:
- Plenty of potential technical contributors are regular users of English Wikipedia.
- The big majority of them are not aware that we have plenty of open source projects and activities welcoming developers as well as other technical contributors.
- The big majority of them don't follow mediawiki.org, the Wikimedia Blog, Village Pumps, our mailing lists or our social media.
- Therefore we are basically not talking to them, even if they visit "us" regularly.
Proposed drivers for a strategy:
- Tight collaboration with English Wikipedia: we are both interested in turning some of those readers in technical contributors improving (among other things) the software running English Wikipedia.
- Work on news and activities with an impact in mainstream tech media: raising the awareness among potential contributors at large.
- Collaboration with established organizations: many active groups out there have an interest in doing technical contributions to Wikipedia.
We are doing a bit of each, but through disconnected activities with more improvisation than common strategy. We are still patching away problems as they come. And we invest a lot of energy in many other activities that always struggle receiving enough attention and attendance.
This is also basically the strategy we are following for engaging editors: en.wiki first, take advantage of any media opportunities to pitch the need for more editors, and programs like GLAM or Education to work directly with organizations.
So what if we would focus our little resources in these three areas until we register a clear trend of growth in new contributors?
After a quick first round of feedback:
- We are talking primarily about tapping new readers, not editors. Editors are important too, but they are already contributing and busy. Proposals here must be visible to anonymous readers and not rely alone on watchlists, Village Pumps, etc.
- We need to target well our actions in order to get high signal vs noise ratios, and volumes we can digest. We could potentially reach huge audiences at en.wiki, but also get drowned with noise and a volume of requests we can't handle. Some ideas:
- Agreeing on using the {{mediawiki}} template in Wikipedia pages about topics where we have also information related to them. Someone created it and I actually added it to a few pages as an experiment. Some kept it, but others (more popular and maintained, like "Git") reverted it: en:Special:WhatLinksHere/Template:MediaWiki
- Adding more connections like "For the use of Jenkins in Wikimedia projects, see..."
- Having a category for MediaWiki/Wikimedia tech related pages and run a campaign only to the pages included there. For instance, imagine promoting the Wikimedia Hackathon during 2 weeks to readers of those pages from the Netherlands and surrounding countries.
- Have a banner at en:Web testing to recruit volunteers for our next Browser testing QA week.
- English Wikipedia first doesn't mean only. en.wiki is the most popular by far, tech readers rely on it regardless of their mother tongues and our basic contribution channels are in English-only anyway. But we will welcome collaboration and experimentation with any other Wikimedia project. In fact, even if we push en.wiki first it might well be that we end up seeing results somewhere else first, since other projects might be faster and more adventurous. All is good and will help drawing a general strategy.
The general principle sounds great, and most of the specific ideas listed above are great and good examples of the way we could tackle the issue.
I have to agree with those who removed the mediawiki template in articles, though: those "project X also has info on Y" are generally aimed at providing extra info about the concept itself, detached from its relationship with Wikimedia. In contrast, the Git page and pretty much every documentation page we have here on mw.org are targeted at MediaWiki development and its surrounding ecosystem. After all, this isn't a generic FOSS documentation project, unlike, say, flossmanuals.net. So that kind of outreach seems to be much more suited to disambiguation hatnotes and targeted banners/campaigns, than to that sort of template.
That said, I wholeheartedly agree we ought to invest on those initiatives. We could for instance start a page with the list of MediaWiki/Wikimedia tech related pages, to facilitate marking which already have the appropriate dab headers (and thus provide a quick to-do list for those interested in contributing in this regard). That list would also help pave the way for a banner campaign, so we could use it to start discussing the content of potential banners as well. And it could host the list of ideas above to a more permanent place, where we could further expand it.
Just my 2 cents.
So what's the plan to assess the listed problems? We all have some of our own ideas what the major issues here are, but at this point they appear to be mostly just that - ideas with little proven backing. Need to gather quantifiable data and verify that an issue is real, significant, or presents in the way we expect before worrying about how to fix it, especially since said research often makes more clear what will fix it.
No assessment plan so far. Do you want to propose one? I agree we will obtain better results.
I started by listing current activities plus initiatives that were already started, to map the current efforts. Ontology and Category:New_contributors are related and it is quite straightforward to get them to a decent first iteration. The goal is to identify the key content at mediawiki.org and open the door to the aggregation of related content from the Wikimedia Blog, Bugzilla and perhaps Gerrit.
There are two principle guiding my steps:
- The chronological sequence of events for an absolute newcomer, focusing on the first points of contact first. Like channeling water and starting closer to the source.
- Have a variety of tasks offered here so people with different skills and interests have a chance to contribute to different areas.
Proposing a plan is not my job, nor would I have time. But the need to establish one and carry it out should be clear. We can all sit around talkpages and mailing lists indefinitely, discussing the matter, miming the actions of new users, and even writing a plethora of personas that fit our perecptions perfectly, if we want, and still get essentially nowhere if nobody gets out the door, so to speak, and actually talks to and researches the new users and the problems they face, gathering quantifiable data on where they wind up and how it impacts them when they do.
I should hope that's your job, because if not there appears to be a rather massive hole in this entire process.
The Engineering Community Team is constantly dealing with potential and actual new contributors, getting out of the door and talking to them. We deal regularly with requests arriving from multiple sources and we organize and attend events and talk with people interested in doing a first contribution. The fact that I can't show you research data right now doesn't mean that we are working in an isolated lab.
I understand proposing a plan "it's not your job". I will continue working on a plan while keeping the work-in-progress approach.
Thank you.
And I'm sorry, I didn't mean to be so accusatory. I know you're doing what you can... it just scares me sometimes.
I can say from project manager's point of view that it takes MORE time to prepare MediaWiki developer that Drupal/Joomla developer out of PHP/js programmer.
I've had employees and students, and many of them complains that there is no programming documentation in MediaWiki. This is not true, we have lots of docs for almost every hook, class and function. However I can admit that there is not much materials and article to glue together these specs.
In other words we have good reference manual but bad tutorial. The only thing that I can call 'a tutorial' is this one. It's a big mess now and it needs improvement:
- first things first. i18n, aliases, $wgExtensionCredits and defining configuration variables are NOT the most important parts of the extension
- Where are the BIG ideas? First big idea is that extensions use hooks mechanism. Second big idea is that extensions writes and reads directly from database, unlike plugins in other CMS. Third big idea is that there are two APIs - the PHP classes like Request, WikiPage etc and well-documented client API.
- Documenting the PHP API: Hooks and PHP Classes. I really don't know how to better do that :(
You are totally right. We have so many wiki pages combines with so much overlapping outdated pages, low quality ones...
You gave me an idea: let's mark the pages we MUST keep to high standards in order to attract and keep new contributors. I started using this category: Category:New contributors.
About tutorials for developers, what about
There is something very nice in each of the tutorials
- How to become a MediaWiki hacker - nice entry point. I think this page shold be extended, made prettier to the eye and then advertised everywhere
- How to become a MediaWiki hacker/Extension Writing Tutorial - a bit of a mess but I like the idea of Example Extensions
- How to become a MediaWiki hacker/Workshop - good Lord. Much information but it's a haystack, not tutorial
- Gadget kitchen/Training - can be good intro into one particular topic of gadgets
- Lua scripting/Tutorial - cool
- API:Tutorial - very cool indeed. That's how the documentation should look like
I can add also this page: MVL - such structure is very good idea and it can make a impression of well-documented software. Maybe such table of contents can be added to all developer documentation pages? See how it's done in Semantic MediaWiki user documentation.
You're wrong on i18n, that's a requirement and making it sooner rather than later is better for everyone. ;-) You're right however on tutorials, and the main problem may be that we talk a lot about the API, meaning however only the WebAPI (probably for a bias, that people only want to interact with Wikipedia's data), and the PHP API doesn't even exist at all: I added a mention of the concept only few weeks ago on API.
How can we let people subscribe to activities in order to get email notifications whever there are updates?
Project:New_contributors/Roadmap#Notifications has some ideas about how this can be handled in the future, and Echo (Notifications) & Flow cover this use case in their roadmap. However, what can we do here and now? A simple Google form to collect email addresses in a spreadsheet? A simple web interface to collect those email addresses in a CRM?
The use case is simple:
Penny is interested in helping out in QA activities. She subscribes to receive notifications. She gets a notification whenever there is a new activity scheduled.
The Wikimedia community has tried to solve this problem o top of MediaWiki in several ways, all inefficient: relying on registered users signing up in pages, relying on people watching pages regularly or having email notifications enabled and paying attention to those notifications in the middle of the many other MediaWiki notifications they receive, missing those not willing to signup publicly, risking typos in wiki syntax, vandalism...
In the meantime, the WWW solved this problem around 1996 if not earlier: go to a web page, add your email address and be done with it. Or something along these lines.
(After Ryan Kaldari's feedback)
Well, creating mailing lists would be a possibility.
This is unidirectional communication and we might have many topics to cover. Creating various mailing lists for this might be an overkill but it is indeed a possibility with a precedent (the -announce lists).
We did something along these lines, too: Wikitech-ambassadors.
It just needs to be used correctly.
Actually my reason to CC you was your involvement in Extension:TranslationNotifications. How is that going and how crazy would it be to take the notification part and repurpose it?
How is it going? - I fixed a few bugs there recently and may fix more in the future.
It's a mix of Special:EmailUser and the Global Delivery Bot, but with its own code and heavily internationalized. It's not exceptionally clever - it just sticks some strings together and emails them or adds them to talk pages. We also thought about adding Echo support to it recently.
The main thing with it is that it needs careful design and definition for other tasks.
Depending on how the pages are structured, the Semantic Watchlist extension could potentially be used for this.
Bug 47186 - Please create tech-contributors-announce mailing list
Thank you for the very basic suggestion! :)
... and the resolution is to recycle wikitech-announce. Good!
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#Development 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.
Thinking it further maybe we should change the sequence proposed here even more radically.
I believe the analysis of the problem is right, and nobody has contested it. The divergences come with the solution proposed.
I have put the attention on structural changes and the software needed for them. I believe the vision is right, and the more I read about E2 & E3 projects & roadmaps I can see that we are basically in the same path. I thought that we could take some shortcuts while those teams deliver the real thing but there seems to be a minority agreeing on this. Fair enough, and probably rightly so.
Let's look at the areas that can be improved in our current sites, then:
- Content and design of mediawiki.org & wikitech.wikimedia.org homepages and the main venues for contributors.
- Good templates offered for user profiles, events, projects.
- MediaWiki / Bugzilla / Gerrit / Wikimedia Blog integration, with a common ontology and content aggregation.
- Full use of Extension:GettingStarted.
- Full exploit of the possibilities of Echo and Flow.
Even more changes: this is now Project:New contributors. If you care about new contributors please watch this page, join the discussion and contribute ideas and work.
This is not about a specific implementation proposal anymore, neither about Wikitech alone. This pages and whatever subpages we need is where we discuss and collaborate way to be more effective reaching to new contributors and connecting them to new tasks.
I still need some time to fully edit the main page but I hope you get the idea.
We need to measure the success of this project as we implement it. For this we need data points.
Some of the data points are based on users, e.g.
- Are they finding better what they are looking for?
- Are new contributors getting a first task faster, and is there a higher % that completes it and goes for a second one?
- Are there more participants in our community activities and is the increase related to the features implemented?
- Are the community metrics improving in active participants in MediaWiki, Bugzilla, Gerrit?
Some data points are based on our own community management and outreach efforts.
- Are we growing our pool of identified contributors?
- Are we optimizing the effort required to promote successfully an activity?
- Are we optimizing the effort invested in maintaining homepages, calendars, news feeds, lists of tasks for new contributors...?
More ideas for data points welcome. As soon as we have a consolidated list I will integrate it to the proposal.
The Engineering Community Team is in a good position to evaluate the current situation and the needs for improving the community contribution channels. We put a bunch of manual editing and template juggling around pages like
There is a Request for proposals / Statement of work for vendors interested in being involved in the development of this project. We are still discussing this proposal in the community, but in any case we need a better idea of the resources and budget needed. If you have any questions please contact me.
Ah, at first I thought it was a proposal to make more public RFP/calls for bids in WMF contracts. :)
The specifications don't include anything about mass deportation of content that are proposed on this RfC, even though that's one of the biggest hurdles. Actually I don't see how the tasks there relate to the proposal here except for SMW user profiles... maybe I didn't read the RfC carefully enough but I'm sure many didnd't pay more attention than me.
«Create a template or extension for Tasks, allowing users to create and categorize tasks with minimum effort based on Bugzilla reports»: looks like an effort to make our bugzilla more similar to mingle, but via an appendix on MediaWiki. O_o
Indeed, the proposal doesn't include subcontracting content migration to a vendor. This is a task we can do. See Technical_communications/Dev_wiki_consolidation#Steps and discuss further if you wish in that wiki page.
Tasks is not about replacing or duplicating any of the tools we have, but about advertising existing bug reports (primarily) in MediaWiki pages. Still needs discussion, but it should be something like adding the URL of a bug report and obtaining a Task in MediaWiki with the same summary, comment 0 and keywords, generating also a notification to users watching those keywords.
This project needs to be useful to OpenHatch and other external mentorship projects interested in helping new contributors getting involved in our community:
- We already would make their work easier by identifying and publicizing tasks looking for new contributors, and also potential contributors together with their semantic profiles connected to Gerrit, Bugzilla and Labs.
- We can have them as a tag that would allow us to retrieve dynamic pages about who is intersted in e.g. OpenHatch, what tasks have been accomplished in the context of OpenHatch projects and by whom... We need to define requirements for this.
- We can also look at how to integrate better with their services via their or our API. More discussion and requirements is needed here.
There is a potential scenario for outsourcing parts of the contributor management and outreach to OpenHatch or a similar organization. Personally I don't think this is an option for us. We are part of a big Wikimedia movement, volunteer contributions is at the very core of our mission, no other Wikimedia project is outsourcing this work and I don't see a reason for us to alter this. BUT I don't think (neither I want) to do all the work by ourselves, especially when there are many organizations, like OpenHatch, willing to help us. Good collaboration with them is a strategic priority and this project should reflect this.
We need to define better the requirements for notifications, and how much of it could be covered by the Echo notifications framework right now or in the following months. Related to this, we need also to know what role could Flow play here.
Our needs for this project today are potentially similar (the same?) than the needs of Wikimedia contributors at large tomorrow. Maybe we can be a test bed for new deployments and experiments?