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:Support desk is the correct place to ask for help on issues related to operating MediaWiki.
An evolved proposal is being handled at Phab:T85602. Further discussion should continue there.
We don't need to run any survey to be sure that:
Proposed drivers for a strategy:
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:
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:
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.
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:
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
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.
We are flexible with the development priorities.
Prototyping one small feature at a time.
Community evaluation based on results and lessons learned.
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:
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.
Some data points are based on our own community management and outreach efforts.
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:
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?
