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_sou…
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.
