În sâm., 16 mar. 2019 la 15:55, David Barratt dbarratt@wikimedia.org a scris:
Perhaps a better example would be the Drupal community who has a total of ~1,071,600 issues and ~282,350 of those are open https://www.drupal.org/project/issues and they have several organizations https://www.drupal.org/organizations working on the software.
Maybe, maybe not - I'm not familiar with Drupal development, but precisely because of the fragmented contributions, chances are some bugs fall between teams. As discussed previously in the thread, MW development is much more centralized, so better coordination is to be expected.
That being said, their org stats are pretty awsome, is there any way to obtain similar stats from Phabricator/Gerrit (at least by email domain if nothing else)?
I do not understand how a large backlog is a problem. It is not an indication of anything.
A large backlog by itself is not alarming. A growing one for components deployed to WMF sites is. It indicates insufficient attention is given to ongoing maintenance of projects after they are no longer "actively developed", which in turn creates resentment with the reporters.
I've checked the burnup graphs Andre referred to for some of the extensions with high editor visibility (UW, VE, CX) and they all have a similar pattern - huge increase in the first ~12 months after being widely deployed, then a much reduced, but visible, growing rate, with some sharp decreases which correspond to a peak in activity (new team culling the backlog? volunteer developer solving a few bugs?). I tried to compare that with the overall pattern, but Phabricator timed out - if somebody could obtain and publish the overall burnup rate data somewhere, that would be great.
I guess the question is what's an acceptable backlog growing rate (key secondary question: for who?) and if it is different between projects. I don't know how to respond to that.
On Fri, Mar 15, 2019 at 12:25 PM Strainu strainu10@gmail.com wrote:
În joi, 14 mar. 2019 la 22:23, Gergő Tisza gtisza@gmail.com a scris:
About backlogs in general, Chromium is probably the biggest open-source Google repo; that has currently 940K tickets, 60K of which
are
open, and another 50K have been auto-archived after a year of inactivity. (As others have pointed out, having a huge backlog and ruthlessly closing tasks that do not get on the roadmap are the only two realistic options, and the latter does have its advantages, no one here seems to be in favor of it.) We have 220K tasks in total, 40K of which are open, so that's in the same ballpark
That's an overstatement: 18% (not counting bugs closed as declined) is almost double to 11%. If you're going this route, we're doing much worse than Chromium.
On Wed, Mar 13, 2019 at 3:02 PM Strainu strainu10@gmail.com wrote:
The main problem I see with the community wishlist is that it's a process beside the normal process, not part of it. The dedicated team takes 10 bugs and other developers another ~10. I think we would be much better off if each team at the WMF would also take the top ranked bug on their turf and solve it and bump the priority of all the other bugs by one (e.g. low->medium). One bug per year per team means at least 18 bugs (at least if [1] is up to date) or something similar.
Community Tech is seven people and they do ten wishlist requests a year. (Granted, they do other things too, but the wishlist is their main
focus.)
So you are proposing to reallocate on average 1-2 months per year for
every
team to work on wishlist wishes. That's about two million dollars of
donor
money. How confident are you that the wishlist is actually a good way of estimating the impact of tasks, outside of the narrow field where editors have personal experience (ie. editing tools)?
I'm 99.9% sure the wishlist is relevant in at least half the categories (Admins&patrollers, Bots&Gadgets, Editing, Notifications, Programs&Events, Watchlists, Wikidata, Wikisource, Wiktionary) and very likely (80%) also for Anti-harassment, Categories and Maps.
I'm not sure how you arrived at the $2M figure (even 36 months of dev time - 18 teams, 2 man-months/team - only add up to ~$400K, unless Glasdoor is waaay off on the salaries there [2]), but presumably going down on the list will also surface bugs and not only features, which will take less time to solve. Investing an additional 1% of the revenue into this seems reasonable to me.
[2] https://www.glassdoor.com/Salary/Wikimedia-Foundation-Salaries-E38331.htm
UploadWizard is not in active development currently.
I did not claim (or asked) that it was. What I said is that it is an important part of the infrastructure and that it should be maintained properly. I also said I will try to come up with a more detailed critique later on and see if it has any result.
Strainu
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l