[webkit-dev] Patch process - let's make it better

[Luke Kenneth Casson Leighton]

> Hi everyone,
>
> One common topic for discussion has been how to make our process
> around patch submission better. As the project grows, it's becoming
> more important for this process to work really smoothly, and we are
> seeing some breakdowns.

 well, this is interesting - some good timing on sending this message.
 i believe it would be reasonable to say that regarding #16401, "breakdown"
 would be an understatement of the first order.

> I've been doing a lot of thinking about this,
> and discussion with some project old hands. I think the right way to
> tackle this is to identify the process problems, and make sure we
> address each one.

 yes.

 perhaps, as i have been on the receiving end of some quite shit and
 unnecessary treatment, i can help give some insights here.

 1) there is no charter for webkit.

 one absolutely vital thing which prevents problems is to have a
 charter which outlines, up-front, the expectations and development
 of the project.

 the apache foundation charter states clearly that:

 * "developers shall treat each other with mutual respect".

 * "contributions shall be considered on technical merit"

 for the freedce foundation, after the samba fiasco in which continuous
 goal-post moving and technical bullying was utilised to make significant
 technical contributions - and their contributors - look like shit, we
 modified this to:

 * "contributions shall be considered on strategic technical merit"

 providing a charter clearly outlines an encouraging environment,
 and also allows you to gently - or forcefully - bring people back
 into line.

 in the case of webkit, then, a charter containing these vital
 guidelines would have stopped the disrespectful treatment i got
 absolutely dead in its tracks.  if a free software developer says,
 "no, i am a free software _contributor_, not a paid-up employee
 whom you can [effectively] _demand_ [sponge off].  i don't have time or
 money to give more than i have to get this issue dealt with",
 it xxxxing well means "no, you can't ask for more than i've already
 gifted to this project", and the people who were asking should,
 instead of getting stroppy, go "oh - sorry, i apologise for that!
 i didn't mean in any way to .... etc." and generally indicate
 gratitude for, and respect for, the contributions made.

 read the comments on #16401 bearing in mind that they are _free_
 and _unpaid_ contributions (not funded by any company or sponsor),
 and watch the breakdown in the conversation due to assumptions made
 by apple paid-up employees - it's very interesting reading.

 2) there are no branches

 the KDE development process has what, over a hundred contributors.
 they don't step on each others' toes.  why?  because the committers
 are allowed to create branches.

 a branch, with relaxed conditions, allows people to collaborate
 BEFORE quotes landing quotes and still feel like they are part of
 the project.

 take the #16401 work as a classic example: with over 5,000 lines,
 not one of the groups of contributors could "officially" collaborate
 on improvements because the contributors had no central "official"
 place in which to collaborate, to meet the over-strict and far too
 time-consuming "review" requirements.

 also, if you look around, there are one hell of a lot of unofficial
 branches of webkit.  i found _yet another one_ recently, this time by
 intel, as part of their 3D desktop project!

 intel should never have felt it necessary to create a separate
 repository: they should have been _invited_ to have commit rights.

 there are plenty of scripts out there that can protect commits to
 branches etc.  so the main trunk can be protected.

 3) the review process is hostile and confrontational.

 it even says, up-front, "this process may seem daunting".
 that's got to stop.  i would not be surprised if the confrontational
 approach is a hang-over from internal apple development ethos.

 it doesn't work in the free software world: if you're going to state,
 up-front, "we're going to be tough on you", then potential contributors
 will just say "sod you, then" and walk away.

 4) automation of coding standards checking

 this is trivial to do.  hindent immediately springs to mind.
 it could even be added as a commit hook to trunk (leaving branches
 alone of course).

 5) assumptions that people know where to read about webkit standards
    and processes

 there seems to be an assumption that people know all about webkit's
 "standards", and irritation and in some cases outright hostility when
 people with enthusiasm and the willingness to contribute simply are
 not aware of these "standards".
 5) assumptions that people know where to read about webkit standards
    and processes

 there seems to be an assumption that people know all about webkit's
 "standards", and irritation and in some cases outright hostility when
 people with enthusiasm and the willingness to contribute simply are
 not aware of these "standards".

 why _should_ they be?  where in the world is it made clear?
 how do contributors find _out_ that there are these standards and
 processes?

 both i _and_ adam, in contributing to #16401, had absolutely no idea
 about the "review" process.  absolutely not a damn clue.

 so we both sat there wondering why the bloody hell nobody from
 apple was looking at the patch, and nobody bothered to tell us,
 either.

 in the case of #16401, due to the size that the patch had to become
 in order to do even the most basic of testing, that led to some
 problems [understatement].  the time to _catch_ those problems was
 wayyyy back at the beginning of the development process, and it was far
 too late to catch them, even a few weeks on, and it's thanks to nobody
 explaining what "review" is.


overall, then, the "patch" process is only half the story.  it's the
support _behind_ the patch process that's far more important, and key
to that support infrastructure is to have respect for the abilities
and the available resources of contributors, and to trust the
contributors to commit [their resources, time and abilities] to the
project.

if you look carefully at everything i've said, you will see that my
comments are a mixture of indicating respect for the reviewers'
technical ability and contributions whilst also absolutely _not_
letting them get off the hook for stepping over the line, and saying
so in no uncertain terms.

from experience, i know that when i say things to projects (that
people don't like), they can get _really_ stroppy about it, and do
stupid things like censor me from mailing lists.

yet, six months to six years down the line, i do a periodic check, and
i find that *other people* are still complaining about exactly the
same issues that i'd raised.

so - with me, you get an "advance warning".  a litmus test, so to speak.

bottom line: look at #16401, and _learn_ from it.

l.