Talk:Campaigns

Esam Idris

@Esam_Idris Hello! Are you trying to sign up to become a beta test organizer? This isn't the page to do it, but I see you already signed up on the appropriate page, so you will be included. Thank you! --IFried (WMF) (talk) 20:53, 20 December 2022 (UTC)

Translations?

If this is to be the portal for all-things CAMPAIGNS it should be available for translation...no? Zblace (talk) 12:08, 5 October 2020 (UTC)

Campaign proposal: tech development campaign

I'd like to propose a new campaign for MediaWiki development (and some other core and select Wikimedia tools) with a banner above software or programming-related Wikipedia articles for volunteer devs. They would point to a campaign with things like leaderboards, badges, gamification, brief descriptions of interesting/needed code changes, internal attention, possibly some external media reporting, prizes (maybe also anonymous bounties), and prioritized weighted issues.

Is this a place to propose such a campaign? Where would be a better place? I also listed such a campaign as one of the (partly synergistic) options to increase MediaWiki contributors here.

The simple version would look similar to this and would have a table of volunteers sorted by numbers of code issues implemented with a sortable column of total story points (sum of e.g. difficulty and/or importance per issue) of implemented issues during the campaign. Top 30 volunteers for example could get some prize money, some certificate, and/or a verified badge for e.g. their user page. It's simple, doesn't cost money (except a small amount of money if there are indeed prizes etc), and makes development engaging and fun. Real-world hackathons may be fun but it's unlikely to be an efficient way to actually get new MediaWiki devs at scale – I think such a virtual longer-term campaign would be much more effective. If this is not the place to propose this, please let me know where else.

All those Wishlist surveys and e.g. technical needs surveys are nearly pointless if things never get implemented. This also inhibits innovation as before implementing innovative new projects like this to name just one as it may often be easier and/or more important to first implement what's needed in MediaWiki core. For example, take a look at the audio file player (example) – it's hopelessly outdated, tiny and can't even skip back 10 seconds when listening to a spoken Wikipedia audio all of which for example contradicts this strategy direction. The Commons app is currently developed by volunteers and neither has a feed/Explore page nor can it play audio or video files. Most goals have some element or requirement of technical development and the current capacity is not even enough to fix major bug-like problems in time like the dysfunctional interactive charts or the problem of hiding bot edits also hiding prior human edits. There's many examples like that and all of it comes from or is linked to a disastrous neglect of technical development capacity building. A campaign like proposed here is a way one wouldn't even have to spend money to hire developers – just making use of established ways to motivate and engage people to develop as volunteers would make a big difference and even a small difference in technical development capacity could help solve so many issues (including several other campaigns are about) and realize so much more potential. I think such a campaign is the most needed one at this point. Please consider it. Prototyperspective (talk) 00:12, 12 October 2024 (UTC)

Generally that sort of thing requires a lot of effort and setup to make sure new devs can succeed. Without people and structure in place, the new contributors just get frustrated and leave. In my opinion (which is probably controversial and not shared by others) we have a ton of "interested" devs, we just throw most of that interest away. I don't think there is much point trying to attract new devs, without a plan to actually retain them. I don't think gamification matters when volunteers leave due to long code review waits. (That said, I do think programs like GCI in the past were really cool). Bawolff (talk) 02:32, 31 October 2024 (UTC)

1. This thing could be done with a large span of effort – doing this with a lot of effort with some great design would probably be ideal but I think doing it with very little effort, like just throwing a simple AI-built header up and linking it to a wiki page that then volunteers can worry about, would also be great already. There's multiple ways to show the above all pages in Category:Software engineering but if all of them are too difficult for now then the banner could also simply be shown above all articles (for a shorter time).
2. When it comes sure to making sure new devs can succeed: this isn't about some psychology kindergarten program to make sure everybody is winning and feeling great, it's about giving people who are interested (and motivating this interest) an option to contribute; some don't like it, some abort early, some love it and some have mixed feelings about it. That's perfectly fine.
3. New contributors wouldn't join to then leave anyway. Nothing lost. Moreover, if they didn't like it at first they can return at a later point but this "leave" makes no sense, nobody is leaving.
4. Let's say it requires some effort and setup: that would be very efficient and the most needed effort since a lot of technical issues waiting on development capacity could then be addressed subsequently after development capacity has increased. I don't think there is anything that WMF could do that would be more important, more urgent, and more justified than increasing technical development capacity. To me, they're still throwing millions out of windows and this wouldn't even require 10 k, actually not even 1 k and maybe no dollar at all.
5. "interested" devs, we just throw most of that interest away No, you don't throw it away, you do nothing with that interest like facilitating that they act on this interest and click on some reminding banner that leads to a motivating table of volunteer devs by number of phab issues solved + interesting issues to implement, a link to a page that describes how to set the dev environment up, and a talk page + irc link where they can ask questions.
6. trying to attract new devs, without a plan to actually retain them , […] due to long code review waits Such plans would also be good. I think 70% or so of devs would stay regardless of whether or not there is such a plan if they got something merged into the code and have become familiar with the code / set things up so they can actually develop. For this, the code of pull requests / … from this campaign would be reviewed quickly obviously. Certainly ways to speed up code reviews would also be good, such as increasing the number of reviewers, prioritizing reviewing changes of new devs, or making code review a task integrated into some tasks system.

Prototyperspective (talk) 12:56, 31 October 2024 (UTC)

I think 70% or so of devs would stay regardless of whether or not there is such a plan if they got something merged into the code - That is a big "if". I think most potential devs leave because they work really hard to solve some problem, submit their code, and then silence. This is really disheartening. Even a "no" is better, since at least that is an answer. I suspect the number of developers would increase by 10 or even 20 times, if there was some assurance that if you did work, you got some sort of constructive response within 72 hours (Whether that be a yes, a no, or a concrete explanation of what needs to be changed to get a yes). Even getting a response like that within a month for p90 of patches would probably increase the volunteer developer community significantly. We don't need to attract new developers, we need to stop actively driving them away with indifference.

I do think having a plan is important - if we try to attract people, but then ignore their contributions, that creates bad feelings, which makes it hard to attract them in the future. This creates a reputation which makes it harder to do campaigns in the future. Like if we try to attract people only to set them up to fail, what is the point?

I think this is one of the reasons why programs like GCI worked so well. It wasn't just gamification and advertising. It also involved picking out tasks for people to chose from, with the promise that the person who suggested the task would review it. It was actually possible for people to fix said tasks. A campaign where the people running the campaign are willing to look at the work submitted as part of the campaign would be something I can get behind. However if doing that I'm not sure advertising would be necessary as there are already plenty of people around the wikimedia communities who would probably finish any such list of problems very quickly. Bawolff (talk) 22:00, 31 October 2024 (UTC)

• Makes sense. I don't think it's a stopgap to this however (you wrote it as if it was or seem to think so), just a problem that also needs to be addressed and if possible before or alongside the things I've suggested. Do you have ideas how the problem you described could be addressed as in increasing the timely "constructive response"? I already made three draft-stage ones increasing the number of reviewers, prioritizing reviewing changes of new devs, or making code review a task integrated into some tasks system which I could make more specific and more readily-adoptable. A fourth would be tracking code reviewing & constructive responses to facilitate people to make more of them.
• We don't need to attract new developers Strongly disagree. I think most people who have submitted some phab issues or participated in Community Wishlists would also disagree and I linked several other people's calls for change regarding this in the MediaWiki page linked above (example) we need to stop actively driving them away with indifference Why not both – both of these things are needed; ideally in parallel. However, do you have any substantiation of what you claim there? Like some statistic that shows most volunteer devs only submitted one or so constructive pull request but then never did anything more or some pages where people describe frustrations with this?
• if we try to attract people, but then ignore their contributions, that creates bad feelings Agree, good point. So adding to my proposal would be that their changes need to be reviewed quite quickly. I thought this was already implicitly included in the proposal via e.g. the leaderboard of volunteer devs by code issues [columns for number and total story points] implemented (they need to get reviewed and get merged / approved for later merging quickly for this to even work)
• advertising would be necessary Why ever you call it advertising, it's not advertising; it's recruiting and that's overdue and entirely irresponsible to not do (except for having a small hard-to-actively-find unmotivating "Developers" link at the bottom).

Prototyperspective (talk) 14:22, 1 November 2024 (UTC)