Re: [Wikitech-l] [Wikimedia-l] let's elect people to serve on the wikimedia engineering community team! (brainstorming)
Hi Quim, Thanks for the invitation. I did not attend Wikimania but would be interested in setting up an office hour to discuss ideas about improving features design and development, including TechCom and the roles of tech ambassadors, ECT, and ECL in features. Could we set up a time off-list? Pine On Aug 8, 2014 1:10 AM, Quim Gil q...@wikimedia.org wrote: On Fri, Aug 8, 2014 at 8:34 AM, Pine W wiki.p...@gmail.com wrote: Quim, it seems to me that the methods used by Features have repeatedly produced troubled results over the years, so it's time for a different approach. Note that the approach of empowering Tech Ambassadors to explicitly represent the voice of the content communities hasn't been tried yet. To me, this is also a different approach. Grantmaking has a community-intensive approach to making major decisions and I think the same approach should be taken in Features. I am optimistic that embedding the community deeply in leading Features would be a long-term change for the better. I believe that the Tech Ambassadors aren't empowered to make high-level community recommendations about Features as the Technical Committee is intended to do, although Tech Ambassadors may want to volunteer to serve on the Technical Committee and/or be integrated into its work. I would like to invite you and the Tech Ambassadors to participate in the discussion about the Technical Committee on the Board Noticeboard [1]. The Wikimedia Engineering Community Team can work here and now on the specific goal of let's empower people to serve on the Wikimedia Engineering Community Team. We can work with the 'people' interested to bring them closer to the development process and tell them how to participate in it effectively. This line of work doesn't get in the way of a potential Technical Committee. I just think that if a committee like that should exist, their potential members should be active at e.g. https://www.mediawiki.org/wiki/Wikimedia_Engineering/2014-15_Goals and related planning pages already today, because the possibility to ask and influence already exists. Anyway, I should have a shower and some breakfast before running to Wikimania. If you happen to be in London and you find this topic exciting, I will be very happy to share a chat with or without coldBeverage(). ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] let's elect people to serve on the wikimedia engineering community team! (brainstorming)
Quoting MZMcBride: ...the two issues (a rush to deploy features versus resource allocation for unwanted features), while sometimes intertwined, can certainly also be discrete. I agree with you in this point, and the Technical Committee is intended in part to improve both situations. Quoting David: Unfortunately - and we quite definitely saw this in the VE introduction - it leaves a lot of them in the position of customer service ablative firewall, the designated targets of people's frustration. Yes, and this is unfortunate. I sometimes feel that the Community Advocacy and Engineering Community Liaison groups get blame for decisions that were made by other people, and these liaisons are placed in the difficult position of trying to please everyone. I have sympathy for the people in those roles and I feel that they often do good work for the WMF and the community. Quim, it seems to me that the methods used by Features have repeatedly produced troubled results over the years, so it's time for a different approach. Grantmaking has a community-intensive approach to making major decisions and I think the same approach should be taken in Features. I am optimistic that embedding the community deeply in leading Features would be a long-term change for the better. I believe that the Tech Ambassadors aren't empowered to make high-level community recommendations about Features as the Technical Committee is intended to do, although Tech Ambassadors may want to volunteer to serve on the Technical Committee and/or be integrated into its work. I would like to invite you and the Tech Ambassadors to participate in the discussion about the Technical Committee on the Board Noticeboard [1]. Pine [1] https://meta.wikimedia.org/wiki/Board_noticeboard ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] let's elect people to serve on the wikimedia engineering community team! (brainstorming)
On Fri, Aug 8, 2014 at 8:34 AM, Pine W wiki.p...@gmail.com wrote: Quim, it seems to me that the methods used by Features have repeatedly produced troubled results over the years, so it's time for a different approach. Note that the approach of empowering Tech Ambassadors to explicitly represent the voice of the content communities hasn't been tried yet. To me, this is also a different approach. Grantmaking has a community-intensive approach to making major decisions and I think the same approach should be taken in Features. I am optimistic that embedding the community deeply in leading Features would be a long-term change for the better. I believe that the Tech Ambassadors aren't empowered to make high-level community recommendations about Features as the Technical Committee is intended to do, although Tech Ambassadors may want to volunteer to serve on the Technical Committee and/or be integrated into its work. I would like to invite you and the Tech Ambassadors to participate in the discussion about the Technical Committee on the Board Noticeboard [1]. The Wikimedia Engineering Community Team can work here and now on the specific goal of let's empower people to serve on the Wikimedia Engineering Community Team. We can work with the 'people' interested to bring them closer to the development process and tell them how to participate in it effectively. This line of work doesn't get in the way of a potential Technical Committee. I just think that if a committee like that should exist, their potential members should be active at e.g. https://www.mediawiki.org/wiki/Wikimedia_Engineering/2014-15_Goals and related planning pages already today, because the possibility to ask and influence already exists. Anyway, I should have a shower and some breakfast before running to Wikimania. If you happen to be in London and you find this topic exciting, I will be very happy to share a chat with or without coldBeverage(). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] let's elect people to serve on the wikimedia engineering community team! (brainstorming)
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 svetl...@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_outreach.jpg https://www.mediawiki.org/wiki/Project_talk:New_contributors#English_Wikipedia_first_26213 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. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] let's elect people to serve on the wikimedia engineering community team! (brainstorming)
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 q...@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 svetl...@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_outreach.jpg https://www.mediawiki.org/wiki/Project_talk:New_contributors#English_Wikipedia_first_26213 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 wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] let's elect people to serve on the wikimedia engineering community team! (brainstorming)
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. -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] let's elect people to serve on the wikimedia engineering community team! (brainstorming)
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_source_project_and_you 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. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
