With due notes that I just yesterday updated my nick and my e-mail, and I'm the one who started this thread;
On Wed, 6 Aug 2014, at 06:58, Quim Gil wrote:
- encourage feedback by absolutely /anyone/ about the next features they'd
like,
Betas and Bugzilla today. Phabricator should make it easier to provide feedback in a wider range of topics, not only "bugs".
99% of users of Wikimedia projects don't /know/ about these tools. That's the problem, and your response is not reflecting it.
- run programming and documentation activities requested (or started) by
community [there would be a lot of small projects, unlike the big ones the current Teams are working on],
I for one would welcome more initiatives and requests from the community. The PyWikiBot is a good example of a team that asks us to help organizing and promoting their special activities. More proposals are welcome.
Listening to me (or other mailing list members) here or in your personal e-mail is not the way to go, as mentioned in my earlier line.
- encourage localising documentation for, and centralising the location
of, all community-developed programming work,
Nemo has been a very active advocate, and I want to believe that WMF teams have been increasingly relying on centralized and translatable documentation in their releases, asking explicitly for translation help.
I had trouble talking with Nemo. He doesn't go in lengthy discussions about development and explaining things on IRC. Is he more willing to follow-up and give examples over e-mail? Probably; I have not tried.
On the plus side, I've had infinitely nice experience with him regarding translations of documentation.
- raise awareness of community development efforts across all Wikimedia
projects,
This is an explicit goal for Tech Ambassadors and Community Liaisons.
Related message: http://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073696.html
- actively encourage members of community become MediaWiki and Gadgets
hackers in the Free Software philosophy?
Ah, you are touching a point of my personal ToDo list that I know we are not addressing as well as we could.
That is correct, and is the problem.
Still, we are trying to focus this line of activity in conjunction with our participation in Google Summer of Code, FOSS Outreach Program for Women, and recently also Google Code-in and Facebook Open Academy.
Those, and IEG/PEG grants, scratch only a very small part of the userbase, and only their bigger projects. The problem is with engaging a vast majority of userbase in scripting the software to meet their personal needs.
See, for instance, with Firefox, customizing is exceptionally easy using existing add-ons or writing your own using the Jetpack. These are well-documented technologies and they're also, unlike what happens at Wikimedia projects, well advertised to end users.
"Would you like to see MediaWiki as openly customizable as Firefox?"
This would be, in my view, a relatively small, collaboration-type team
(with just half a handful of people for timezone coverage for IRC support).
To me this is not a task of one team or two, but a set of practices better embodies in our development and deployment processes, and also a set of activities that a larger community should embrace.
In fact, this is what my Wikimania session is about! Shameless plug:
https://wikimania2014.wikimedia.org/wiki/Submissions/The_Wikimedia_open_sour...
Wikimania people are a tiny part of the userbase. _How_ would you do what you're talking about there? This is not mentioned in the abstract, even though the problem raised is similar.
(It was scheduled at the "Technology, Interface & Infrastructure" track but believe me, it's more about WikiCulture & Community.)
I'm curious about the subject of you message, especially the "let's elect people" part. What do you mean?
Community volunteers could be featured for their technical work, and get rigorous feedback from community. If some of them start doing it contrary to community expectations, there should be means to clearly display that (and kick them out if they start doing rubbish and fail to hear the said feedback). -- This is very unclear and unspecific. I would expect others to come up with a specific mechanism for such cases.
Svetlana.