I'm delighted to see a document that is clear enough to encourage useful comments from non-techies (on some parts of it)
I have 5, at increasing levels of specificity
1) At least in the US, the need for increasing contributions by underrepresented groups is not limited to women. Various ethnic groups in the US are even more under=represented. But I'm not sure how much of this is solvable by technology, either for them or for women.
2) The user retention goals are not the province of engineering alone, or even for the most part. Attracting initial contributors will indeed be greatly helped by Visual editor, but the enWP people will need considerable convincing about both features and interaction with the current editor and current procedures before doing what most needs to be done, making it the default for non-loggged in users. The other aspects are primarily that of improving the social environment and on-wiki processes at the individual WPs & Commons, and more effective work by the various chapters and associated projects. Flow will be of some help here, but it isn't the critical factor. I d I think the decline not only may be irreversible but ought to be expected to be irreversible: WP is no longer the most exciting thing in the world to the extent that it can have the same attractive power as in the first few years.
3)I have never understood the need for Flow- I find the existing talk page systems quite functional. But since many others don't find the current system satisfactory. the one place Flow should not be trialed on the enWP is the Teahouse, which has its own distinctive system. It should rather be trialed on places where there is long and particularly intricate discussions and were beginners are not likely to be confused.
4) The most intractable conflicts at enWP arise from the need to apply brief descriptive phrases or words to situations that ae inherently ambiguous. A system for category searching by intersection would eliminate about half the problems.
5) Perhaps this should be put off till the following year, but a system for constructing articles from infoboxes populated by wikidata would essentially give a fill in the blanks interface for constructing many types of articles. This would help beginners, and people writing in other than their native languages.,
On Fri, Jun 27, 2014 at 3:55 AM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Erik Moeller, 27/06/2014 03:55:
As an update on the goals process for WMF engineering, we've begun
fleshing out out the top priorities for the first quarter.
This has already been an interesting and useful exercise, I feel. Those are indeed goals which need help from everyone who can. Which brings me to:
[...]
- The content API that Gabriel is working on (
https://www.mediawiki.org/wiki/Requests_for_comment/Content_API ) is called out as a top priority. This is because the Parsoid output (for which the content API will be a high performance front-end) is now getting to the point where it's starting to become plausible to increasingly use it not just for VisualEditor, but also for views as well.
This is something I encourage everyone on this list to play with. I spent a couple days on Parsoid's output for it.wiki and it's been fun, finding many things to report: while reasonable pages are rarely very broken, on a random page there is some 50 % chance of finding some visual glitch.
My favourite toy to this purpose is Kiwix:
- download a recent file for your favourite wiki at
http://download.kiwix.org/zim/wikipedia/ ,
- download Kiwix to open it http://download.kiwix.org/nightly/bin/latest/
,
- start pressing "random page" and report surprises e.g. to
https://sourceforge.net/p/kiwix/bugs/
Nemo
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe