Hi everyone!
Community Tech will be dealing a lot with technology relevant to Wikimedia editors. We figured we'd introduce ourselves here, hoping some of you might want to help out connecting us with the communities.
We're a new team within the Wikimedia Foundation, focused on meeting the needs of active Wikimedia editors for improved, expert-focused curation and moderation tools. Making the lives of the people who spend a lot of time taking care of the Wikimedia projects a little bit easier. This is a small team: myself, Frances Hocutt and Niharika Kohli, with some support from Johan Jönsson as a Community Liaison. We'll focus on tasks that can be dealt with quickly and that will have a direct benefit for the core community and might be overlooked by the larger WMF development teams.
To find our feet, we’ve mainly been knocking out bugs during the first weeks. At the moment, we're looking at tasks from previous surveys to see how we can benefit the communities. We are also working on developing a good process for soliciting new requests from the Wikimedians we're responsible for helping. As part of this effort, we have written up a draft proposal ( https://www.mediawiki.org/wiki/Community_Tech_team/Community_Wishlist_Survey) for a cross-project community wishlist survey that we would like to launch within the next month or two. Please take a look at the draft, share it with your communities, and let us know your thoughts on the talk page.
You can find more information, such as the scope of the team, a roadmap, what we're doing and what we've done so far on our team page: https://www.mediawiki.org/wiki/Community_Tech_team
Ryan Kaldari Engineering Manager, Community Tech
Hello Community Tech team,
Welcome to this list!
I think it is great that in WMF there is a team now that is collecting the needs from the community and turns this in software improvements. This sounds to me as a great improvement.
Concerning the section Outreach, I am not sure how many wikis have such, but there still exist technical ambassadors who serve as an intermediate between the tech and the community. From the tech side the ambassador translates software changes into text with enough contest and clear wording for local users on wikis, and informs the community about software changes and more. From the community side the tech ambassador translates problems, issues, feedback and more to the tech side. For the Dutch wikis I serve as technical ambassador to have the interaction tech-community go more smoothly.
Abouth the sections of Phase 1 & 2 I am concerned. The way it is suggested to be set up now is that the proposals with the most votes win. First of all, large wikis & communities have more people to submit proposals and more people to vote. So it seems that this is becoming a popularity contest, which is the wrong direction. In the Dutch community it happens a lot that users are against certain software, until they tried, and the other way round happens as well. Basing a voting on what people like can easily become unbalanced because of various factors. Also what matters to one person, does not have to matter to another person (like because he doesn't do anything with it), while it can be essential to another.
Also I think that the survey is missing an important factor: what level of importance does a certain software have. This can't be determined by a voting. The determination can vary, but I see three different importancy levels: 1. software that is broken or cause troubles, while it is essential 2. software that is missing and needed to get a core process running 3. software that is helpful, extra, handy, but not part of a core process
That still level ones exist is a piece of past heritage, sadly.
Another subject that recently came up is the subject of continuity. One of the largest announces I notice is that users see that software is no longer maintained, but still like to use it, are getting very annoyed. This is not an issue that is incidental, it is a structural problem.
In general speaking I am happy with the team and the survey, but I think it will need some improvements before it can be used in a balanced way.
Greetings, Romaine
Reading the Community Wishlist Survey page I think it is a great idea to do.
2015-08-25 21:54 GMT+02:00 Ryan Kaldari rkaldari@wikimedia.org:
Hi everyone!
Community Tech will be dealing a lot with technology relevant to Wikimedia editors. We figured we'd introduce ourselves here, hoping some of you might want to help out connecting us with the communities.
We're a new team within the Wikimedia Foundation, focused on meeting the needs of active Wikimedia editors for improved, expert-focused curation and moderation tools. Making the lives of the people who spend a lot of time taking care of the Wikimedia projects a little bit easier. This is a small team: myself, Frances Hocutt and Niharika Kohli, with some support from Johan Jönsson as a Community Liaison. We'll focus on tasks that can be dealt with quickly and that will have a direct benefit for the core community and might be overlooked by the larger WMF development teams.
To find our feet, we’ve mainly been knocking out bugs during the first weeks. At the moment, we're looking at tasks from previous surveys to see how we can benefit the communities. We are also working on developing a good process for soliciting new requests from the Wikimedians we're responsible for helping. As part of this effort, we have written up a draft proposal ( https://www.mediawiki.org/wiki/Community_Tech_team/Community_Wishlist_Survey) for a cross-project community wishlist survey that we would like to launch within the next month or two. Please take a look at the draft, share it with your communities, and let us know your thoughts on the talk page.
You can find more information, such as the scope of the team, a roadmap, what we're doing and what we've done so far on our team page: https://www.mediawiki.org/wiki/Community_Tech_team
Ryan Kaldari Engineering Manager, Community Tech
Wikitech-ambassadors mailing list Wikitech-ambassadors@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors
Welcome, CT!
Romaine Wiki wrote:
Another subject that recently came up is the subject of continuity. One of the largest announces I notice is that users see that software is no longer maintained, but still like to use it, are getting very annoyed. This is not an issue that is incidental, it is a structural problem.
+1 I think orphaned gadgets maintenance will/should be an important task for this team. There many gadgets created a long time ago, that were maintained and improved for years but now are orphaned with lots of editors still using them. Editors that are unhappy each time they break (api changes, document.write bans, sajax being gone, and most recently that they must use ResourceLoader to continue working…).
On Tue, Aug 25, 2015 at 6:29 PM, Platonides platonides@gmail.com wrote:
Welcome, CT!
Romaine Wiki wrote:
Another subject that recently came up is the subject of continuity. One of the largest announces I notice is that users see that software is no longer maintained, but still like to use it, are getting very annoyed. This is not an issue that is incidental, it is a structural problem.
+1 I think orphaned gadgets maintenance will/should be an important task for this team. There many gadgets created a long time ago, that were maintained and improved for years but now are orphaned with lots of editors still using them. Editors that are unhappy each time they break (api changes, document.write bans, sajax being gone, and most recently that they must use ResourceLoader to continue working…).
We're actually collecting reports of broken gadgets on Phabricator currently and trying to fix them as we have time: https://phabricator.wikimedia.org/T108282. Normally we will only be working on tasks that are submitted through some sort of formal process (see https://www.mediawiki.org/wiki/Community_Tech_team#Work_input_and_prioritiza...), as we don't have the capacity to field random requests from all the communities. The huge number of gadgets that have broken recently (due to various core MediaWiki changes) is something of a crisis though and we want to help get them back up and running. TheDJ (who is not on our team) has also been helping with gadget fixes. There are a lot of gadgets out there, so any additional help (or bug reports) are welcome.
On 8/26/15, Ryan Kaldari rkaldari@wikimedia.org wrote:
On Tue, Aug 25, 2015 at 6:29 PM, Platonides platonides@gmail.com wrote:
Welcome, CT!
Romaine Wiki wrote:
Another subject that recently came up is the subject of continuity. One of the largest announces I notice is that users see that software is no longer maintained, but still like to use it, are getting very annoyed. This is not an issue that is incidental, it is a structural problem.
+1 I think orphaned gadgets maintenance will/should be an important task for this team. There many gadgets created a long time ago, that were maintained and improved for years but now are orphaned with lots of editors still using them. Editors that are unhappy each time they break (api changes, document.write bans, sajax being gone, and most recently that they must use ResourceLoader to continue working…).
We're actually collecting reports of broken gadgets on Phabricator currently and trying to fix them as we have time: https://phabricator.wikimedia.org/T108282. Normally we will only be working on tasks that are submitted through some sort of formal process (see https://www.mediawiki.org/wiki/Community_Tech_team#Work_input_and_prioritiza...), as we don't have the capacity to field random requests from all the communities. The huge number of gadgets that have broken recently (due to various core MediaWiki changes) is something of a crisis though and we want to help get them back up and running. TheDJ (who is not on our team) has also been helping with gadget fixes. There are a lot of gadgets out there, so any additional help (or bug reports) are welcome.
This seems kind of backwards. A bunch of changes were made, things exploded, and now Community tech is going to try to desperately fix them.
Maybe this is a sign we need to re-evaluate how we do client-side deprecations.
-- -bawolff
2015-08-26 8:45 GMT+02:00 Brian Wolff bawolff@gmail.com:
This seems kind of backwards. A bunch of changes were made, things exploded, and now Community tech is going to try to desperately fix them.
Maybe this is a sign we need to re-evaluate how we do client-side deprecations.
I couldn't agree more: since document.write has been deprecated and non ResourceLoader-enabled gadgets have been disabled, tens of gadgets have been broken on many wikis, some of them being actually used by many editors. Now, three weeks later, all gadgets have not yet been fixed, the breaking changes have not been temporarily reverted and angry users are still complaining almost everyday about stuff being broken.
What about fixing first and deprecating after? At least when it's technically feasible like for code in the MediaWiki: namespace.
BTW, thanks to Ryan and Ori for their precious help in fixing what remains broken on the French Wikipedia!
On Tue, Aug 25, 2015 at 5:42 PM, Romaine Wiki romaine.wiki@gmail.com wrote:
Abouth the sections of Phase 1 & 2 I am concerned. The way it is suggested to be set up now is that the proposals with the most votes win. First of all, large wikis & communities have more people to submit proposals and more people to vote. So it seems that this is becoming a popularity contest, which is the wrong direction.
I actually suspect that the proposals that will get the most votes will be ideas that benefit the most projects. If an idea would only benefit French Wikipedia, for example, I doubt it would get as many votes as a tool that is usable by every Wikipedia. That said, I do agree that some projects are probably going to be at a disadvantage. For example, I'm not expecting WikiSpecies to make a strong showing. To some degree, this makes sense, as we want to focus our limited resources where they will have the largest impact. We also want to make sure, however, that we are not ignoring vital sectors of the community. We haven't fleshed out plans for it yet, but we have some very tentative plans to do focused technical workshops with specialized community groups next year. For example, we might hold a workshop for GLAM volunteers or Wiktionary volunteers or Recent Change Patrollers to find out what their specific needs are and how/if we can address them. This idea is dependent on what kind of resources our team has next year and is very tentative, so don't hold me to it just yet. Right now, it's just an idea :)
In the Dutch community it happens a lot that users are against certain software, until they tried, and the other way round happens as well. Basing a voting on what people like can easily become unbalanced because of various factors. Also what matters to one person, does not have to matter to another person (like because he doesn't do anything with it), while it can be essential to another.
These points are all true and this is the reason we will be offering feedback on as many of the proposals as we can before voting begins. Specifically, we will try to assess them for feasibility, impact, and risk, so that voters can make well-informed choices rather than just voting for their favorite gadget. Also, keep in mind that voting isn't the final step for prioritization. After voting is finished, we will be taking the top X requests (probably 10 or 20) and then doing our own analysis of them to determine priority. It's possible some of those requests will be referred to other teams or even rejected if they don't make sense for us to work on.
The process for this survey is still a draft, however, and we are open to significantly revising it. If you have suggestions for a system that might work better than voting and you can show community support for the idea, we can switch to a different process. The current draft is based largely on consultations with the German TCB team (which has done similar wishlist surveys), the WMF Community Engagement team, and a few random community members that we've talked to. I'm sure it isn't perfect, but I doubt any process will be.
Ryan Kaldari Engineering Manager, Community Tech
Hi Ryan,
Sorry for the delay, a lot of work came in between.
I actually suspect that the proposals that will get the most votes will
be ideas that benefit the most projects. Still, a large community like the English and the German community have an overly weight on the balance simple by the fact they are with more people. I think this unbalance has a larger effect on the votes than the factor if the benefit of the most projects. The idea of that the ideas that benefit the most projects get the most votes is in the ideal situation a really great point of view, but such requires high penetration in the communication in reaching the users around the world. (This seems almost a request for improvements in the communication as bug first, and while that would be great, that is not the point.)
Maybe I should explain why I write this. In my area I organise a lot of courses, writing sessions, etc and with organising this we notice that for new users the provided online working environment is almost completely (yes, that worse) insufficient to continue editing. We also notice that existing users have found their working environment and do not care much about the difficulty new users have, as they often seem to think: I can, so they should too be able to find it for themselves. The we is just a few people who organise most activities and see the effects of it. While almost everyone in the movement think editor retention is important to improve, because many do not have the experience in organising writing sessions, workshops, etc nor are out for feedback from new users why they actually stop with editing, they do not realise that Wikipedia is missing something for new users. And those new users are already gone or do not speak out mostly...
If you think you like to continue with the votes for the ideas that are considered the best in the movement, I would like to suggest at least one change in set up: organise it in such way that you create categories. Like a category what the Wikidata users need, what the existing editors on Wikipedia need, what the Commons users need, what the organisers of workshops/writing sessions/etc need, etc.
Greetings, Romaine
2015-08-26 9:22 GMT+02:00 Ryan Kaldari rkaldari@wikimedia.org:
On Tue, Aug 25, 2015 at 5:42 PM, Romaine Wiki romaine.wiki@gmail.com wrote:
Abouth the sections of Phase 1 & 2 I am concerned. The way it is suggested to be set up now is that the proposals with the most votes win. First of all, large wikis & communities have more people to submit proposals and more people to vote. So it seems that this is becoming a popularity contest, which is the wrong direction.
I actually suspect that the proposals that will get the most votes will be ideas that benefit the most projects. If an idea would only benefit French Wikipedia, for example, I doubt it would get as many votes as a tool that is usable by every Wikipedia. That said, I do agree that some projects are probably going to be at a disadvantage. For example, I'm not expecting WikiSpecies to make a strong showing. To some degree, this makes sense, as we want to focus our limited resources where they will have the largest impact. We also want to make sure, however, that we are not ignoring vital sectors of the community. We haven't fleshed out plans for it yet, but we have some very tentative plans to do focused technical workshops with specialized community groups next year. For example, we might hold a workshop for GLAM volunteers or Wiktionary volunteers or Recent Change Patrollers to find out what their specific needs are and how/if we can address them. This idea is dependent on what kind of resources our team has next year and is very tentative, so don't hold me to it just yet. Right now, it's just an idea :)
In the Dutch community it happens a lot that users are against certain software, until they tried, and the other way round happens as well. Basing a voting on what people like can easily become unbalanced because of various factors. Also what matters to one person, does not have to matter to another person (like because he doesn't do anything with it), while it can be essential to another.
These points are all true and this is the reason we will be offering feedback on as many of the proposals as we can before voting begins. Specifically, we will try to assess them for feasibility, impact, and risk, so that voters can make well-informed choices rather than just voting for their favorite gadget. Also, keep in mind that voting isn't the final step for prioritization. After voting is finished, we will be taking the top X requests (probably 10 or 20) and then doing our own analysis of them to determine priority. It's possible some of those requests will be referred to other teams or even rejected if they don't make sense for us to work on.
The process for this survey is still a draft, however, and we are open to significantly revising it. If you have suggestions for a system that might work better than voting and you can show community support for the idea, we can switch to a different process. The current draft is based largely on consultations with the German TCB team (which has done similar wishlist surveys), the WMF Community Engagement team, and a few random community members that we've talked to. I'm sure it isn't perfect, but I doubt any process will be.
Ryan Kaldari Engineering Manager, Community Tech
Wikitech-ambassadors mailing list Wikitech-ambassadors@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors
Hi Ryan,
Thanks for the information and good luck with your team building itself and getting down to business.
Philosophically, it would be interesting to hear how the team will be addressing issues at a sister-community development level.
Traditionally, there has been the apparent focus on tools for the Wikipedias (and one can see how that happens), so it would be interesting to hear how you will be lifting your focus to the broader wikimedia wiki issues. This is especially important as sometimes decisions made for the Wikipedias have an unexpected adverse impact on the sister wikis. A recent example would be the recent categories to recent changes/watchlists where it was premature in its release due to its impacts outside of the WPs. I know that the sister wikis are smaller and slower in responding to developments, so it would be great to see how we can utilise the available tools like beta. Similarly, how the community-tech team can may be lead in helping those of us outside of the WP-hub to get our needs aligned within the broader WMF scope.
Regards, Billinghurst
On Wed, 26 Aug 2015 05:54 Ryan Kaldari rkaldari@wikimedia.org wrote:
Hi everyone!
Community Tech will be dealing a lot with technology relevant to Wikimedia editors. We figured we'd introduce ourselves here, hoping some of you might want to help out connecting us with the communities.
We're a new team within the Wikimedia Foundation, focused on meeting the needs of active Wikimedia editors for improved, expert-focused curation and moderation tools. Making the lives of the people who spend a lot of time taking care of the Wikimedia projects a little bit easier. This is a small team: myself, Frances Hocutt and Niharika Kohli, with some support from Johan Jönsson as a Community Liaison. We'll focus on tasks that can be dealt with quickly and that will have a direct benefit for the core community and might be overlooked by the larger WMF development teams.
To find our feet, we’ve mainly been knocking out bugs during the first weeks. At the moment, we're looking at tasks from previous surveys to see how we can benefit the communities. We are also working on developing a good process for soliciting new requests from the Wikimedians we're responsible for helping. As part of this effort, we have written up a draft proposal ( https://www.mediawiki.org/wiki/Community_Tech_team/Community_Wishlist_Survey) for a cross-project community wishlist survey that we would like to launch within the next month or two. Please take a look at the draft, share it with your communities, and let us know your thoughts on the talk page.
You can find more information, such as the scope of the team, a roadmap, what we're doing and what we've done so far on our team page: https://www.mediawiki.org/wiki/Community_Tech_team
Ryan Kaldari
Engineering Manager, Community Tech
_______________________________________________ Wikitech-ambassadors mailing list Wikitech-ambassadors@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors
wikitech-ambassadors@lists.wikimedia.org