I've started the code review of the r56150:HEAD range. Eventually I
will branch the trunk and create both a new wmf-deployment and a 1.16
release.
There are 3500 revisions and 3 months of development effort to review.
It's going to take me a long time despite the fact that my examination
of many components will be very brief.
If you want to help, here is what you can do:
* Fix things that are marked in CodeReview as "fixme". Please do this
even if you are not the original author.
* Focus on quality in your regular development work. Test your changes
before you commit them. Finish what you started.
* Review code and write comments.
Because some people use "resolved" to indicate that some small part of
the revision was fixed, despite glaring issues in the remainder, I
treat all "resolved" statuses as needing review. If a partial review
has been done, I'd prefer to see a new -> fixme -> new sequence,
instead of new -> fixme -> resolved.
Unlike last time I did this, I am respecting some of the OK status
flags set by other people. But please do not set any revisions as OK
unless you are really sure they are OK in every way. I'd rather see
people working on setting fixme statuses and leaving the OKs for me.
The exception is the review work that I'm deferring. Any sort of OK is
better than deferred.
Please do not mark your own changes as "ok" or "resolved". Please
review my changes, because I don't like to be hypocritical on this
point and will be setting them to "deferred" if nobody else is
interested in looking at them.
I think the usability initiative team is large enough and experienced
enough that they should be able to review their own changes. I'll be
doing some whole-file reviews but I'd like to avoid reviewing the
individual revisions.
-- Tim Starling