Change Details

**Type of activity:** Pre-scheduled session **Main topic:** How to grow our technical community == The problem == The technical contributors to WMF projects are primarily WMF employees. WMF tends to "lick the cookie" when it adds tasks to its roadmap, even if the WMF doesn't have the engineering resources to accomplish the task anytime soon. Without an active non-staff community, experimental projects take a backseat to incremental maintenance work and firefighting. Without an active non-staff community, "WMF groupthink" sets in, and the WMF loses practice adopting projects which were "not invented here". Without an active non-staff community, WMF can't deprecate lesser-used code and have it adopted by loving community members. == Expected outcome == Discussion of alternative mechanisms to leverage community developers. As a starter proposal, we submit the idea of using the IdeaLab process internally to WMF for roadmap tasks which are more than a quarter or two in the future. By aggressively documenting these "like to have" projects we allow community members to help us achieve our goals faster than we would otherwise. == Current status of the discussion == ...See IRC summary in comments below... == Related links == * https://meta.wikimedia.org/wiki/Better_maps_of_all_the_movement_work

**Type of activity:** Pre-scheduled session **Main topic:** How to grow our technical community == The problem == The technical contributors to WMF projects are primarily WMF employees. WMF tends to "lick the cookie" when it adds tasks to its roadmap, even if the WMF doesn't have the engineering resources to accomplish the task anytime soon. Without an active non-staff community, experimental projects take a backseat to incremental maintenance work and firefighting. Without an active non-staff community, "WMF groupthink" sets in, and the WMF loses practice adopting projects which were "not invented here". Without an active non-staff community, WMF can't deprecate lesser-used code and have it adopted by loving community members. == Expected outcome == Discussion of alternative mechanisms to leverage community developers. As a starter proposal, we submit the idea of using the IdeaLab process internally to WMF for roadmap tasks which are more than a quarter or two in the future. By aggressively documenting these "like to have" projects we allow community members to help us achieve our goals faster than we would otherwise. == Current status of the discussion == ...See IRC summary in comments below... == Related links == * https://meta.wikimedia.org/wiki/Better_maps_of_all_the_movement_work * {T118231}

**Type of activity:** Pre-scheduled session **Main topic:** How to grow our technical community == The problem == The technical contributors to WMF projects are primarily WMF employees. WMF tends to "lick the cookie" when it adds tasks to its roadmap, even if the WMF doesn't have the engineering resources to accomplish the task anytime soon. Without an active non-staff community, experimental projects take a backseat to incremental maintenance work and firefighting. Without an active non-staff community, "WMF groupthink" sets in, and the WMF loses practice adopting projects which were "not invented here". Without an active non-staff community, WMF can't deprecate lesser-used code and have it adopted by loving community members. == Expected outcome == Discussion of alternative mechanisms to leverage community developers. As a starter proposal, we submit the idea of using the IdeaLab process internally to WMF for roadmap tasks which are more than a quarter or two in the future. By aggressively documenting these "like to have" projects we allow community members to help us achieve our goals faster than we would otherwise. == Current status of the discussion == ...See IRC summary in comments below... == Related links == * https://meta.wikimedia.org/wiki/Better_maps_of_all_the_movement_work * {T118231}