Hi.
There was a time when the software being run on Wikimedia wikis was updated about weekly. Nowadays, I honestly can't remember the last time it was fully SVN upped and scapped, and the branching has made it nearly impossible for me to figure out where the progress stands. A few "critical" revisions get merged into the 1.16wmf4 branch as necessary, but most revisions are left untouched, as far as I can tell.
I'd like to see if there are ways to get back to more regular site software updates. Should the branching be undone so that trunk has to be usable? Is it a matter of developer man-power? Is it a matter of code review? I'm not trying to be critical, but the current situation seems far less than ideal. I'm willing to help if I can, as I'm sure others are, but it seems like nobody's quite sure what or where the exact problem is.
It's also possible that not everyone views the lack of software updates to be a problem. That itself might be an issue that needs to be addressed.
MZMcBride
On Mon, Aug 9, 2010 at 3:38 PM, MZMcBride z@mzmcbride.com wrote:
There was a time when the software being run on Wikimedia wikis was updated about weekly. Nowadays, I honestly can't remember the last time it was fully SVN upped and scapped, and the branching has made it nearly impossible for me to figure out where the progress stands. A few "critical" revisions get merged into the 1.16wmf4 branch as necessary, but most revisions are left untouched, as far as I can tell.
This is a real pain, I agree. If you're doing something with the intent that it be used on Wikipedia, it must be pretty demoralizing to not see your changes ever go live. This also greatly increases the headache when we finally do deploy the many months of changes to the live site. And the current practice of deploying some arbitrarily-chosen subset of revisions out of order is prone to cause bugs -- wasn't that what caused us to lose all those images a while back?
I'd like to see if there are ways to get back to more regular site software updates. Should the branching be undone so that trunk has to be usable? Is it a matter of developer man-power? Is it a matter of code review? I'm not trying to be critical, but the current situation seems far less than ideal. I'm willing to help if I can, as I'm sure others are, but it seems like nobody's quite sure what or where the exact problem is.
I'm pretty sure it's a problem of code review. Deployment was already getting erratic in Brion's final months here, as he and Tim couldn't keep up with the pace of new commits, and it pretty much ground to a halt when Brion left. I'm going to go out on a limb here and guess that the problem is we have many more developers than we did two or three years ago, but no more reviewers.
Surely a few paid people can be assigned to make sure everything is reviewed, in place of some of their current coding duties. If we had three or four people doing review, the workload on each wouldn't be terribly great. They might not be as experienced as Brion or Tim, but the worst that happens is buggy software gets deployed once in a while. Which will happen anyway, and we can fix it when it does. I think we long ago passed the point where it's worth the risk.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 37-01--10 03:59 PM, Aryeh Gregor wrote:
Surely a few paid people can be assigned to make sure everything is reviewed, in place of some of their current coding duties.
Don't we already have staff for this? Hasn't "and finally get code review and deployment up to pace" been part of several hiring announcements over the past year or more? I appreciate that getting people to the place where they can do good code review takes time, but if that's what the problem is, then emails like this should immediately be met with exactly that explanation.
Or perhaps I hallucinated that the Foundation hired staff for this sort of thing.
- -Mike
Hi Mike,
I think you may be hallucinating. We are just now hiring our second code-reviewer, who is also thinking about ways to make the code review process more transparent.
Danese
On 8/12/10 4:49 PM, Mike.lifeguard wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 37-01--10 03:59 PM, Aryeh Gregor wrote:
Surely a few paid people can be assigned to make sure everything is reviewed, in place of some of their current coding duties.
Don't we already have staff for this? Hasn't "and finally get code review and deployment up to pace" been part of several hiring announcements over the past year or more? I appreciate that getting people to the place where they can do good code review takes time, but if that's what the problem is, then emails like this should immediately be met with exactly that explanation.
Or perhaps I hallucinated that the Foundation hired staff for this sort of thing.
- -Mike
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAkxkiIoACgkQst0AR/DaKHvETACgvRrBgjXtlBC2iFcINm1QQecP M6MAnRZEk2iq7PaMHnYV3KyWmF/4u6CS =0EVt -----END PGP SIGNATURE-----
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Aug 12, 2010 at 8:49 PM, Danese Cooper dcooper@wikimedia.org wrote:
I think you may be hallucinating. We are just now hiring our second code-reviewer, who is also thinking about ways to make the code review process more transparent.
Is this someone with a lot of MediaWiki experience? If not, how are they supposed to review code? I'd think it would be much more sound to ask a couple of existing employees to pitch in instead, spending part of their time reviewing and part of it coding. I can think of a couple of people who are qualified enough. It doesn't make a lot of sense to have someone who only reviews and doesn't code, unless they've already done so much coding that they're very familiar with the codebase and coding conventions anyway.
I also wonder how the review process could be more transparent, since it's already completely public and open for anyone to join in (and plenty of random non-developers do join in).
2010/8/13 Aryeh Gregor Simetrical+wikilist@gmail.com:
they supposed to review code? I'd think it would be much more sound to ask a couple of existing employees to pitch in instead, spending part of their time reviewing and part of it coding. I can think of a couple of people who are qualified enough. It doesn't make a lot of sense to have someone who only reviews and doesn't code, unless they've already done so much coding that they're very familiar with the codebase and coding conventions anyway.
I second this. The only way to become good at reviewing MediaWiki code is to write MediaWiki code for at least a year. I had been a dev for 3 years by the time I felt comfortable reviewing code, but then I hadn't been doing it full time. Someone working full time and being coached by experienced reviewers should be able to get up to speed in less than a year, IMO. This would still be quite a long time, though, so hiring people specifically for code review should be understood in that context.
However, the fact that it takes so long to get a good grip on reviewing code suggests that reviewing code is just something that senior developers do, and that newly hired developers will be able to review code a few years from now. If we have our existing senior developers do more code review, educate all of our developers about code review better, and just hire more developers to initially cover the void of senior devs doing less coding and more review and later to join the reviewers, I believe we'll have a much more sustainable and sane setup than we would get by hiring people specifically for review and having them focus on review from day 1.
I also wonder how the review process could be more transparent, since it's already completely public and open for anyone to join in (and plenty of random non-developers do join in).
I would also like to hear specific suggestions here. I think there are things that could be done to improve our code review process in terms of making sure code gets reviewed in a timely fashion and by the right person. (I have some ideas about that just occurred to me today, so I'll take the time to think about them and hash them out more while I'm on vacation, and maybe post them next week.) However, it's not clear to me how transparency could be improved. All the data is already made available, all that could be improved AFAICT is making it easier to obtain.
Roan Kattouw (Catrope)
On Fri, Aug 13, 2010 at 4:10 PM, Roan Kattouw roan.kattouw@gmail.com wrote:
However, the fact that it takes so long to get a good grip on reviewing code suggests that reviewing code is just something that senior developers do, and that newly hired developers will be able to review code a few years from now. If we have our existing senior developers do more code review, educate all of our developers about code review better, and just hire more developers to initially cover the void of senior devs doing less coding and more review and later to join the reviewers, I believe we'll have a much more sustainable and sane setup than we would get by hiring people specifically for review and having them focus on review from day 1.
Yep. And we could do this immediately. So why aren't we? Slow code review, and consequent slow deployment and release, has been probably the biggest problem with MediaWiki development for at least a year.
On Fri, Aug 13, 2010 at 4:33 PM, Roan Kattouw roan.kattouw@gmail.com wrote:
I think I know almost all developers we contract and what they do, but that's only because I proactively stay on top of things by e.g. asking new people who they are and what they do when they appear in the staff channel.
Apparently this isn't a reliable strategy, since I'm technically a Wikimedia contractor right now, but no one invited me to any special channels. (I say "technically" because I did a few hours of work and got to the point where I couldn't do much more without review, which I've been waiting for for more than two weeks.)
Danese Cooper wrote:
I think you may be hallucinating. We are just now hiring our second code-reviewer, who is also thinking about ways to make the code review process more transparent.
The area of contractors and Wikimedia hires has to be one of the most opaque parts of Wikimedia. Unless someone is fully certified as a member of the staff and is listed at wmf:Staff,[1] there is almost no way to figure out who's working for Wikimedia, in what capacity, and for what duration. The only real recourse available to contributors is to directly ask each individual person whether or not they're staff, and sometimes they'll answer.[2]
For an organization that prides itself on openness and transparency, I don't see how it's acceptable to intentionally keep the list of people Wikimedia is hiring that are doing code development work a complete secret. I've personally asked Erik to have people listed on some sort of page on the WMFwiki, but apparently the overhead for a simple ordered list is too high.
Without being able to know who's working on what or when or why, it makes it so much harder for people not hired by Wikimedia (the ones who do the majority of the code development) to collaborate with the ones who have been hired (or partially hired).
I can say that the majority of code development work I've been seeing lately from people working for Wikimedia is Usability-related or fundraising-related. If there are code reviewers being hired to do general code review, mind pointing me to a reliable source saying so?
MZMcBride
[1] http://wikimediafoundation.org/wiki/Staff [2] http://en.wikipedia.org/?oldid=364616662#Are_you_Wikimedia_staff.3F
2010/8/13 MZMcBride z@mzmcbride.com:
The area of contractors and Wikimedia hires has to be one of the most opaque parts of Wikimedia. Unless someone is fully certified as a member of the staff and is listed at wmf:Staff,[1] there is almost no way to figure out who's working for Wikimedia, in what capacity, and for what duration. The only real recourse available to contributors is to directly ask each individual person whether or not they're staff, and sometimes they'll answer.[2]
For an organization that prides itself on openness and transparency, I don't see how it's acceptable to intentionally keep the list of people Wikimedia is hiring that are doing code development work a complete secret. I've personally asked Erik to have people listed on some sort of page on the WMFwiki, but apparently the overhead for a simple ordered list is too high.
Yes, this is bad. The problem is that currently, we simply do not have such a list, not even internally. It desperately needs to be compiled and made public. At one point, Tim started a page on officewiki trying to list all dev contractors because he was taken by complete surprise when someone told him he'd been contracting for usability for a few months already. I think I know almost all developers we contract and what they do, but that's only because I proactively stay on top of things by e.g. asking new people who they are and what they do when they appear in the staff channel. Even then, some contractors manage to elude me and I find out about them long after they've been hired.
Without being able to know who's working on what or when or why, it makes it so much harder for people not hired by Wikimedia (the ones who do the majority of the code development) to collaborate with the ones who have been hired (or partially hired).
People who do work for WMF also have this problem: they are generally more up to speed, but they don't have complete knowledge either.
Roan Kattouw (Catrope)
2010/8/13 Roan Kattouw roan.kattouw@gmail.com:
Yes, this is bad. The problem is that currently, we simply do not have such a list, not even internally. It desperately needs to be compiled and made public. At one point, Tim started a page on officewiki trying to list all dev contractors because he was taken by complete surprise when someone told him he'd been contracting for usability for a few months already. I think I know almost all developers we contract and what they do, but that's only because I proactively stay on top of things by e.g. asking new people who they are and what they do when they appear in the staff channel. Even then, some contractors manage to elude me and I find out about them long after they've been hired.
All contracts go through HR (which currently is only one person, Daniel Phelps). MZMcBride asked me a while ago whether we'd maintain an up-to-date list of comings and goings of all contractors, which I don't think makes sense, simply because many contracts are intentionally short-term engagements without any meaningful community implications (e.g. administrative and in-office support contracts).
However, we can certainly do better in keeping folks in the loop on contracts that have community implications, which includes most tech contracts and of course community dept. contracts. Whether this is through blog updates, a public log page, or by another method, is up to Daniel to figure out, and I know he's working on it, along with a very long list of other things.
wikitech-l@lists.wikimedia.org