Regarding: >My proposal is to begin the discussion here: how can we better relay issues >that are more important to communities than new features? How can we have a >"community whishlist for bugs"?
Well fundamentally it starts with making a list. This is basically a lobbying discussion right. People think WMF should do more of X. Lobbying discussions are more successful the more specific they are. Having a list of the top 20 worse bugs is something you could convince people to do something about. Even something like /WMF spends too much time on new features and not enough time on maintenance/bug fixing/, is something you could convince people to change, if you for example knew how much time WMF currently spends on bug fixing, and you have an idea of how much time you think they should be spending. Even if management doesn't agree with your proposal, it would at least be specific enough to debate. When these discussions start from vague places, like there's too many bugs, is when they go nowhere. Even if WMF stopped everything else it was doing, and worked solely on bugs, I doubt they would fix every bug in existence. (We can't all be TeX!), and attempting to do that would be a bad idea. Change happens when stuff is measurable, and people can work towards a goal. Failing that, change happens when people can be held accountable. Objective measures are needed. -- Brian On Sat, Mar 9, 2019 at 10:31 PM Strainu <strain...@gmail.com> wrote: > Dan, > > Thank you for your response. I appreciate far more someone disagreeing with > me than someone ignoring me :) > > Let me start with a simple question, to put the references to wmf into > context. You keep talking below about volunteer developers and how they can > take over any project. While that's true, how many fully-volunteer teams > are there? How does that number compare to the number of wmf teams? Am I > right to assume the ratio is hugely in favor of wmf teams? Note: teams, > not developers, since decisions on project management are usually done at > team level. > > Pe sâmbătă, 9 martie 2019, Dan Garry (Deskana) <djgw...@gmail.com> a > scris: > > > On Sat, 9 Mar 2019 at 11:26, Strainu <strain...@gmail.com> wrote: > > > > > How many successful commercial projects leave customer issues > unresolved > > > for years because they're working on something else now? > > > > > > > Almost all of them, they just keep it secret. Companies pay millions of > > dollars each year for support packages, even after having paid for > software > > in the first place, specifically because otherwise their support issues > may > > not be answered in a timely fashion, or even answered at all. I don't > think > > comparing us to commercial products makes much sense in this context. > > > In my experience in b2b contracts they don't keep it a secret, they usually > have SLAs they respect, but ok, let's leave it at that. > > > > > There were a > > > number of proposals on how to track such issues so that reporters have > a > > > clear image of the status of the bugs. Have any of them been tried by > at > > > least one of the teams at wmf? If so, is there a way to share the > results > > > with other teams? If not, how can we convince the wmf to give them a > > > chance? > > > > > > > I don't agree with shifting responsibility onto the Wikimedia Foundation. > > > Responsibility for what? Developing and hosting MediaWiki? Helping > communities concentrate on creating and attracting content without having > to work around bugs? I'm sorry, but that's precisely one of the > responsibilities of the wmf and this is what's discussed here. > > > > > There's an anti-pattern here: we all have a big mailing list discussion, > > agree there's a problem, agree that the Foundation should solve the > > problem, then ask again in a year what they did even though they didn't > > actually say they'd do anything about it. That's not a healthy dynamic. > > > This is one thing that we agree on: nobody committed on anything. Ever. > That's why I asked above: what does it take to have someone (anyone) at the > WMF act upon these discussions? > > My role in the Wikimedia tech community is tech ambassador above all else, > so I'm caught in the middle here: I have to explain new features and > technical decisions to people who don't care about php, js or server > performance , but I also feel obligated to relay their requirements, as I > see them, to the development team. This second process does not happen as > smoothly as it should. > > It's not healthy to ignore discussion after discussion and claim it's a > community issue. It's not. It's a governance issue and it's growing every > day. > > > > > > > > The technical space is owned by all of us, so if we, as a technical > > community, decide this is important to us, then we can look at the > problem > > and try to tackle it, and then figure out how the Wikimedia Foundation > > could catalyse that. > > > The projects belong to the community at large, not just the technical > subcommunity. They are the ones affected by the bugs and also they are the > ones that need our support. So why should they be ignored in taking this > decision? > > My proposal is to begin the discussion here: how can we better relay issues > that are more important to communities than new features? How can we have a > "community whishlist for bugs"? > > Cheers and a great weekend to everyone, > Strainu > > > > > Dan > > _______________________________________________ > > 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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
