Talk:Release Management RFP

About this board

MZMcBride (talkcontribs)

I've skimmed Release Management RFP/2014/Mark y Markus LLC just now and I'm having a lot of difficulty understanding why it's appropriate to spend tens of thousands of dollars to make two tarballs. tar is a free Unix program. Announcing the availability of a new tarball via e-mail and IRC is essentially free. MediaWiki is free software. What on earth is all of this money going toward, exactly?

MarkAHershberger (talkcontribs)

Short answer: if the Foundation just wants a team to manage two tarballs, then the only amount that we're asking for is is the amount by "Total technical".

However, with that amount we won't be able to a lot of community building or engaging with larger users. That is something that the Foundation has said that they would like to see -- "the MediaWiki community would benefit from a more diverse set of benefactors for MediaWiki maintenance".

If that is the case, then they really need to help with some seed money for the process. We don't expect this to be ongoing, though, since we expect to get the funding from the user group in the future.

MZMcBride (talkcontribs)

According to Release Management RFP/2014/Mark y Markus LLC, total technical is budgeted at $62,400 per year. That's a lot of money. If, for example, there are two tarballs released a year, what is six hours being spent on per week for release?

I'm not sure what "advocate third-party interests" means, but it will allegedly cost over $12,000. Why?

Same with "new formats of distribution" at over $18,000. You can buy a car for $18,000, but then you'll have a car (a physical, usable good that provides a direct benefit to the driver). What specifically are we getting for the $18,000 here?

I continue to be baffled by the costs here.

Bawolff (talkcontribs)

I tend to agree with MZ here. This seems like a lot of money to essentially put together a tarball

Mglaser (talkcontribs)

A quick clarification: There were roughly 20+ minor release tarballs (monthly, three supported MW branches each), several RCs and two major releases. They were produced following a unified process for security and maintenance, which had to be established. The tarballs were also tested automatically and manually, and the test automation had to be written. So it's not just about two tarballs a year.

Will answer your other questions seperately (later).

MZMcBride (talkcontribs)

To be clear, I like and respect both Marks and all five of the Consortium group. You all are great and I love the work that you all do.

But I'm trying to figure out why MediaWiki releases are seemingly so expensive. If the cost were something like $5,000/year, I wouldn't think twice about the expense. But $130,000/year? I would hope we would have some magical automated release system with lots of bells and whistles if we're spending over $100,000 per year. You could hire two full-time developers who could focus exclusively on development work to make the MediaWiki installer and upgrader better for that kind of money.

Building a user group (a community) doesn't require money, exactly. It ideally should happen organically. Yes, you can invest time (and consequently money) into this type of work, but I'm not sure it's a great idea. It also seems pretty orthogonal to MediaWiki release management. As it is, I'm not quite sure what purpose a user group would serve, but a good part of me also feels that this topic is outside the scope of this talk page.

Rillke (talkcontribs)
and the test automation had to be written

Is it open source?

Legoktm (talkcontribs)

It appears so. I think gerrit:89158 is what is being discussed. Though, it looks like hashar re-wrote a bunch of it, so I'm not sure how much Mark and Markus actually did.

MarkAHershberger (talkcontribs)

What do we mean by “advocate third party interests”?

Here are some recent examples of what “advocate third party interests” means: the recent upload problem in 1.23 (about 2 hours) or the #REDIRECT bug (about 5 hours).

Of course, being available to engage in these unexpected problems takes time, too.

Another example is the one Cindy Cicalese mentioned in her endorsement. She submitted a minor patch to gerrit to add a needed hook to core and wasn't able to find anyone to review it. Because I was at SMWCon in Montreal and made it clear that I was available to help people get things done with MediaWiki, I was able to make sure her patch got the attention it needed.

Reply to "Cost v. benefit"

Why are the items under “Cost of organising user group” distinct?

3
MarkAHershberger (talkcontribs)

One question that came up during the IRC discussion that I wanted to provide more clarification for was this one from Greg:

20:17:06 <greg-g> In the budget section (thanks for that! it's good to have that break down), you have a line for "advocate third-party interests" at 4 hours/week. That one seems very nebulous (there is no definitive definition of what what entails, exactly, in the proposal); can you explain a bit about what you see fitting into that line item vs the first three line items in the "cost of organising (sic ;) ) a user group" section?

The “advocate third party interests” line is just a normal part of making the software available. See my response above for examples of what actually involves.

I tried to provide more detail for the other items below.

Build up and maintain a user group
This involves creating an entity that we can point to outside of MyM as the place for non-WMF users. Four hours a week covers the time needed for planning the work, creating the entity, and engaging people and organisations to participate and be involved in it.
Understand and build up an ecosystem
We need to use data from WikiApiary and performing our own surveys to conduct a full environmental scan to identify the characteristics of our users and active developers to find ways to engage them.
Work towards a developer community
While some of the people currently in the current MediaWiki community are third party developers (for example, the Consortium is made of of people like this), there is an entire group of developers working to extend MediaWiki that are not yet part of the MediaWiki ecosystem. This line actually means that we want to broaden the developer community to include these other developers. We need to draw these people in and show them that there is a market that needs the MW-focused skills that they have.
Legoktm (talkcontribs)
MarkAHershberger (talkcontribs)

You're right, it should be. Still there was discussion here about our proposal and, hey!, LQT!

Reply to "Why are the items under “Cost of organising user group” distinct?"

Subsidiary for commercial support?

4
Brooke Vibber (talkcontribs)

So, since Wikimedia Foundation isn't interested in maintaining MediaWiki itself for third party users, how about we form a subsidiary company to handle commercial support, maintenance, install and hosting services? This could be a for-profit subsidiary, like Mozilla Foundation's Mozilla Corporation, if that makes sense.

I think there's demand for this, and it makes sense to do it under the Wikimedia umbrella.

Nemo bis (talkcontribs)

Who's "we"? :) If you wait for the WMF board of trustees I doubt such a company will ever be formed. On the other hand, if a random guy, say Brion Vibber ;) (or some other MediaWiki devs), opened a company with whatever name and made an offer for this RfP, they could get this contract; and if things go well that company may develop in many ways, for instance becoming a partner organisation or even a Wikimedia thematical organisation named MediaWiki something. Just saying.

MarkAHershberger (talkcontribs)

My impression from discussions I've had (and probably shaped by my own biases) is that there is more interest in another non-profit org to handle this.

In fact, the user group we're proposing this year is meant to demonstrate interest in MediaWiki from outside the Foundation. If the user group is viable, it will take over the release management.

Reply to "Subsidiary for commercial support?"
MZMcBride (talkcontribs)

Eventually it may make sense to move this page to a subpage structure under RFP (expanded, of course). It depends if there will be more of these in the future.

Greg (WMF) (talkcontribs)

Agree. If/when there's another one, I'll do that.

Reply to "Page title"
There are no older topics
Return to "Release Management RFP" page.