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) djgwiki@gmail.com a scris:
On Sat, 9 Mar 2019 at 11:26, Strainu strainu10@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