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.
Hi,
On Wed, 2014-08-06 at 12:01 +1000, svetlana wrote:
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.
I've seen people on Village Pumps etc. complaining about certain software changes introduced. After I provided links to five [sic!] previous announcements, their reply was basically "I didn't see them! Wrong place, you should have put them $here and $there instead".
What is your proposal to _successfully_ make more people aware of such tools, if that's the problem?
There are also enough (note to myself: [citation needed]) Wikipedia readers who don't know that you can edit an article yourself. Everybody has the personal freedom to not be interested in $stuff. Personally I'm fine with driving a car while having no clue why and how a car works.
Cheers, andre
PS: Obviously this is all my personal opinion.
Meta comment: if our common goal is to increase collaboration, then we need to excel ourselves in this collaboration precisely. If we minority of tech-aware contributors are being confrontational between ourselves, then we can only expect to nurture more confrontation than collaboration among the new tech contributors we aim to engage.
So please, let's enjoy this conversation and let's help each other finding better ideas to improve this problem we all want to solve.
On Wed, Aug 6, 2014 at 4:01 AM, svetlana svetlana@fastmail.com.au wrote:
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.
Yes, I agree. Can we do better?
I think the core of the problem is how to increase the participation of tech-curious contributors, and how to structure it in a way that informs, influences, and actually joins the development process effectively.
How can we increase the participation in technical matters among Wikimedia editors and readers? For some thoughts on this topic, see
https://commons.wikimedia.org/wiki/File:Wikimedia_technical_volunteer_outrea... https://www.mediawiki.org/wiki/Project_talk:New_contributors#English_Wikiped...
Increasing participation by volume of participants is a goal per se. However, this participation needs to be somewhat structured in order to become efficient. For instance, having "more Tech Ambassadors" is good, but wouldn't it be better if we all knew which Wikimedia projects and areas of expertise are they covering?
I even think that having a sense of meritocracy among tech ambassadors would be useful, just like it is useful at some point to know who is an official maintainer of a repository, who has been granted permissions to merge new code.
Am I referring to the Technology Committee that Pine is proposing? I don't know. What I know is that tech meritocracy (and any meritocracy) works better when it emerges from the grassroots, and therefore I'm skeptical about any process that would start with a mandate from the Board or with a WMF goal.
There are many smart, productive, and dedicated technical volunteers in our community. In relation to the problems we are describing here, they have an understanding, an experience, and a vision that most board members and WMF employees can't match. I wonder what do they think, what would they do? And I wonder how can the rest of us help them.
Quim, can you clarify your comments about the Technology Committee? The committee is my proposal as a community member; it is not a top-down, Board-created idea. Its membership is designed to be broadly representative of the MediaWiki user community. The Board mandate is necessary to give TechCom similar placement to AffCom, the FDC, and other community-led and Board-chartered committees that report directly to the Board. I am not sure how you see TechCom as anything but a community-based organization.
Pine On Aug 7, 2014 12:33 AM, "Quim Gil" qgil@wikimedia.org wrote:
Meta comment: if our common goal is to increase collaboration, then we need to excel ourselves in this collaboration precisely. If we minority of tech-aware contributors are being confrontational between ourselves, then we can only expect to nurture more confrontation than collaboration among the new tech contributors we aim to engage.
So please, let's enjoy this conversation and let's help each other finding better ideas to improve this problem we all want to solve.
On Wed, Aug 6, 2014 at 4:01 AM, svetlana svetlana@fastmail.com.au wrote:
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.
Yes, I agree. Can we do better?
I think the core of the problem is how to increase the participation of tech-curious contributors, and how to structure it in a way that informs, influences, and actually joins the development process effectively.
How can we increase the participation in technical matters among Wikimedia editors and readers? For some thoughts on this topic, see
https://commons.wikimedia.org/wiki/File:Wikimedia_technical_volunteer_outrea...
https://www.mediawiki.org/wiki/Project_talk:New_contributors#English_Wikiped...
Increasing participation by volume of participants is a goal per se. However, this participation needs to be somewhat structured in order to become efficient. For instance, having "more Tech Ambassadors" is good, but wouldn't it be better if we all knew which Wikimedia projects and areas of expertise are they covering?
I even think that having a sense of meritocracy among tech ambassadors would be useful, just like it is useful at some point to know who is an official maintainer of a repository, who has been granted permissions to merge new code.
Am I referring to the Technology Committee that Pine is proposing? I don't know. What I know is that tech meritocracy (and any meritocracy) works better when it emerges from the grassroots, and therefore I'm skeptical about any process that would start with a mandate from the Board or with a WMF goal.
There are many smart, productive, and dedicated technical volunteers in our community. In relation to the problems we are describing here, they have an understanding, an experience, and a vision that most board members and WMF employees can't match. I wonder what do they think, what would they do? And I wonder how can the rest of us help them. _______________________________________________ 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
wikitech-l@lists.wikimedia.org