> 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.
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
