Where did we go wrong - disillusioned coders

I'll try to cover only points that weren't addressed, or were incompletely addressed, at the summit (see TWikiCommunitySummit2008Q1)

At the summit, the following assertions were minuted:

Some people feel insulted by some developers (code rejected, all contributed code rewritten)

Some developer in the community have been hostile and scared away other new coders from coming in. This is a problem and the hostility must be reduced.

Obviously insults and hostility do not motivate contributors.
Unfortunately there was no opportunity to go into specifics at the
summit, though Peter did say that he had spoken to "developers who
recently left the project" (please correct me if this is wrong). AFAIK no-one has
made a public statement that gives code rejection or rewriting as a
reason for lack of contribution, but we really need to understand how such
a perception could arise, so I've spent quite a bit of time on trying to understand this.

First we have to ask "what is a developer", and why would code be rejected or
rewritten?

I could be wrong, but in this context I think "some developers" is
specifically targetted at those who check in to the codebase. Further,
my guess is that the comment was aimed specifically at core developers,
and not plugin developers.

Rejections

So, what could make someone think their contribution had been rejected?
Fortunately we track all checkins, all reports in Bugs web, all feature
proposals in Codev, we keep logs of all release meetings, all IRC
discussions, and archive the dev mail list, so we can constructively
review all this data to see if we can find where the perception is coming from.

Contributions might be perceived as "rejected" if they are:

slagged off on IRC before they ever reach Codev

slagged off in TWiki-Dev

rejected in Codev at the feature proposal stage

rejected at release meetings

ignored or rejected as bug reports

reverted after checkin

rejected in personal emails from core developer to contributor

Patches are sometimes (very rarely) attached to topics in Codev, and the
contributions are taken into the core by developers as and
when they have time. Some contributions never get the attention of
developers for one reason or another - usually time - and it would be
easy for the author of such a contribution to take that as rejection. However
the number of such contributions is small, and I can't find any evidence of any
being rejected.

IRC

So, what about IRC? IRC is at times dynamic and energetic, and can be
challenging. I suspect that everyone who contributes there has at times
been hostile, and at other times warm and welcoming. I have personally
lost count of the number of times someone has attacked
my ideas, sometimes very aggressively and personally, but
always - I think - with the best interests of Open Source TWiki in mind.
I have formed the impression that in general, it is far more welcoming
than alienating. Flame wars are extremely rare. New contributors who join
to discuss their ideas usually get a cautious, but welcoming, reception.

I only participate during the European day, and not all the time, but I
cannot recall, and cannot find in the logs, evidence of an input being
rejected there. Constructively criticised, yes, but not simply rejected.

TWiki-Dev

In one sense TWiki-Dev, which is a subscription service, is less open than
IRC. But it is also used to communicate more frankly by those who are on the
list. So what proposals were rejected on TWiki-Dev? Well, none that I can
find; though there was a long discussion on the rejection of some 10
enhancement requests from Vicki Brown. AFAICT this rejection was
done via the release process, and didn't actually involve any active
developers. The debate was more about the process than the technical
merits of the ideas (started 24/12/07).

Codev

In 4.2, 7 feature proposals were rejected at the Codev stage. Of these,
3 were proposed by me, 2 by Peter (one of which he retracted) and one each
by Kenneth and Arthur. None of us could be classed as "new coders",
and I think we're all thick-skinned enough to take criticism. A number of
other proposals were parked, but mainly because of lack of a committed
developer.

And proposal rewriting? During 4.2 25 proposals were implemented.
12 of them were proposed and implemented by me. 10 of the rest came from
the "usual suspects" - Sven, Arthur, Kenneth. The other three - which did
come from a new coder (Andrew Jones) - were accepted without much comment,
though one had to be subsequently corrected because of a bug.

Release Meetings

OK, so was it release meetings? Well, there were 28 release meetings during
4.2, so quite a lot of reading.

However AFAICT release meetings tend to reinforce conclusions already made
by the community, and there is no evidence
that I can find of inappropriate hostility or rejection. There were some
tough debates, and a small number of
issues went to public vote during the year. I doubt these public votes
were a source of disillusion.

Bug Reports

Ignored bug reports is another matter altogether. Many people - including
myself - post many reports in the bugs web, many of which never get addressed.
It's possible someone new (besides Vicki) may have felt offended by closure of an
enhancement request, but if so they didn't record the slight. I didn't go
through all the reports, just most of them, so it's still possible that there
were further rejections. We only have a finite capacity for bugfixing,
unfortunately.

Checkin Reversion

Reverting after checkin is something that is usually only done when it causes
test failures, or otherwise breaks an existing feature. I'm not sure why
we wouldn't revert in these circumstances. In the event, I can only find
code permanently reverted for one contributor - a three-line patch to the
UTF-8 encoding that caused a perl segfault. This contributor was slapped down
quite hard, but there was a lot of follow up to try and help them find a better
solution. Unfortunately no one was able to propose any working code.

Private Communication

There's no way to track private communications between one contributor
and another, until they emerge on public lists. AFAIK no problems have
been reported between contributors.

Rewrites

TWiki has been operating on a 12 month release cycle, so it's reasonable -
I think - to assume this comment was aimed at contributions made over
the last 12 months (24 at a stretch). Code older than that is often subject
to refactoring as part of the ongoing development process, as we learn more
and think of better solutions.

Further, some contributions just don't work - they cause test failures, or
break some other documented feature. Authors are usually given an opportunity
to correct their contribution, but if they don't respond, a developer will
sometimes go in and rewrite the contribution so it works.

So, I went in search of contributions made over the last 24 months
that were rewritten. There were two that I could find in the core:

The users code was extensively refactored to allow for external mapping providers. This involved Sven in rewriting a lot of the code I had written for 4.1.2

Several code modules that had been edited on Windows (ctrl+M's) or formatted using tabs were reformatted to the standards

That's not to say there aren't more; I just couldn't find them.

Perception

So I'm struggling to find hard evidence that backs up the idea that code rejection or rewriting is a factor. My memory of the year is less than perfect, and it's quite likely I have missed some events that were important, but it does suggest that the self checks and balances in the process, while not perfect, do work fairly well.

However I don't doubt for a second that Peter reported what he heard, so
this perception has been communicated by at least one person. That's one
too many, so we have to think how we can make sure that new contributors
are not left feeling pushed away.

So, how can a negative perception of the developer environment arise?

It's clear that the complexity of the process (or at least the lack of documentation) has caught people out, and
some rather abrupt comments have been made when no-actioning bug reports.
However I can see no evidence of particular hostility in those comments. There is some evidence that when
discussions are taken onto TWiki-Dev they can spiral. There is further evidence that in times of pressure,
people don't consider all the angles. Even when these slip-ups are resolved to the
original parties satisfaction, an ongoing debate can break out. This is minuted in the summit minutes as "Flame Wars".

One obvious route to disillusionment is through someone new observing such debates
in public forums between developers. Often these debates don't lead to a decisive conclusion, leaving
the issues hanging as the debaters lose energy or back off.

IMHO the problem we face is that we must get issues out on the table for
airing, but we need to do it in such a way that the debate is settled in good time, and closed when
it is settled. This isn't so much of a problem in Bugs web,
but when a debate spills over to TWiki-Dev, the spam can get very irritating. Worse, when it gets to Codev then the acrimony can linger for a
long time - years. It is then available for anyone to read, including new
developers who will inevitably read it out of context (who looks at the last changed date when they read a topic?)

The first and most obvious solution to this would be to ensure that technical debates reach a conclusion, and aren't left
hanging. Also, Codev topics need to be regularly gardened. This has other benefits, which have been discussed
elsewhere. Making discussion inclusive isn't easy to mandate, but also needs to be considered by all parties.

A second approach would be to actually take a backward
step, and keep these debates out of Codev in the first place. Unfortunately
this would take the "open" out of "open source" (and the "wiki" out of
"TWiki"), so probably won't be seen as attractive to most people.

Another problem that has been highlighted several times by Peter, and most recently by Harald in PersonalRoadmapForHaraldJoerg,
is that the developer environment has become overcomplex. It's true, I'm acutely concious of it. There needs to be simplification
in several key areas. We started this with Unit::Test, and are continuing it with Subversion. A simpler system is more likely to
be documented in a way that is accessible to more developers.

Great analysis. I was also wondering if there was any evidence to the claims you analysed in this topic. All I did was check with my own experiences, i only really started joining the community maybe one year ago.

Two things come to mind. One is where I proposed a new feature, by submitting it to the bugs web. It was my first active attempt at contributing, and yes it got rejected. Because, as i learned later, there are other processes for this. At the time, i just thought it got rejected because no-one cared or it was a bad proposal. I do not remember receiving a comment about why my proposal was rejected, but i can't seem to find the report anymore.

I think this has been discussed on the twiki-dev mailing list. All i could add to that: 'if the bugs web is not meant for feature proposals, why do we have a bug category "enhancement" there?'.

Looking at proposing features the 'right way', i have some experience with that. I only recently started going down that route, to commit back some code i wrote for a customer project. The process is a bit bureaucratic, but needed. A recent proposal is my TWikiFormInheritance. It received some resistance, forcing me to clarify. It can be putting off when your contirbution is not accepted unconditionally. It seems to me though, that such a proces is needed, to make sure TWiki stays on track. Just accepting any proposal will lead to inconsistencies and reduced quality eventually.

My point: i could have given up when the first criticism on my proposal came in. That would be easy (and frankly, my first instinct). I could have said 'well you guys are just mean, goodbye'. Would i then be 'scared away' by current developers? Or would i just be a bad teamplayer?

Some concluding remarks: i have never felt any hostility from most of the members of the community. The hostility i've met (i won't rehash that here) does not come from core developers, not on irc nor on codev or the mailing list.

I am in a lot of IRC channels/mailing lists, from different communities. Ranging from embedded linux to twiki, from PostgreSQL to fon. And I must say that the TWiki community is among those where i felt welcome, and i felt i can ask questions without being ridiculed or straight out humiliated in public. These are rare out there! Go visit a random irc channel on freenode, and ask a newbie or silly question. Chances are high that you will be ignored or flamed down. Not so on #twiki.

So given my own experiences, and Crawford's analysis, I do wonder where the substantiation for the claims made at the summit comes from.

I don't care about where they came from; I care about how the perception arose, and what the community can do about it. I suspect your experience may well be typical; it's the process, and the way that some people execute on it. Since anyone coming to Codev (or Bugs web) identifies everyone they meet there as "developers" (or at least everyone who executes the process) then that may well be the source.

Franz, I'm sorry for taking pains. I will try to be more slapdash in future

I think it is a good analysis. It is a "lessons learned" reaction to a perception received. It is good to go back and see what we can do better in 5.0 without accusing anyone and I think this analysis has done this well as it tries to answer the question "what could I have done wrong" more than pointing fingers at anyone. The purpose of this is for sure not to slap anyone but to look at ourselves. It is a fact that we have lost more developers than we have won even though TWiki in itself is a success being downloaded by more and more.

The analysis matches some of the statements I was quoted for during the summit: "Most proposals accepted by 14-day rule or consensus. Rejecting rare." and "Not noticed code rejection as problem".

And I basically agree on the entire analysis and the conclusions that Crawford gives. That is a good thing.

So it must be in the more "soft" and "indirect" way we act towards the new contributors that the root cause to this perception of rejections is to be found. Also I have had to reflect over this. Did I react too tough on some feature proposals? Did I open bug reports towards to contributions that were too hard in the wording?

The problem may actually also lie in what we do not do. Do we receive new people with an open smiling face. Do they get a hug? Or a cold shoulder? Do we say cleary enough where we need them the most? Are the new tasks waiting to be done split in well defined chunks that people can overview and feel safe about working on? Does the presense of few hard working developers in itself seem scary? Maybe people think - "no matter what I touch I step on the turf of this Crawford guy". Or "no matter what I propose that Kenneth guy will look at my proposal with evil suspicious eyes of doom".

Looking forward some things we can consider are

Improving the feature proposal application to be easier to understand. Not more doc but more clear docs.

Remembering that when us old guys discuss each others proposals we also signal how we may discuss features from new guys. Even when we know among each other that we do not mean anything evil with some hard critique new people may see innocent remarks in a negative light. This is something that I will try thinking about in my own wordings in future.

Be more clear on "turf" and try and avoid "turf" in the code. People need to feel that they can touch any part of the code without stepping on other peoples toes. Turf lies in perception. Noone ever said "stay away from my code" when it comes to the TWiki core.

The "temporary turf" that we all de-facto have when we work on a specific feature is often smaller than people realize. We may be working in 2 or 3 source files. It this always made clear?

The roadmap for 5.0 gives us an opportunity and also - IMHO - directly requires more written design - in words - not code. We can try really hard to split up the individual tasks so that new contributors can get a bite of the elephant that they can chew. It may require that some of you most experienced step into more of a role of software architect than coder in some time periods.

The unit test frame work is a real uphill travel for newbies. I can testify to this. Getting the right balance between not having unit tests and make bug fixing easy and having the best possible quality with good unit tests making bug fixing a harder task - is not trivial to address. And we may need to apply different standards to different people. Ie. that we put less requirements on newbies and learners than we do to ourselves. And maybe even bite the bullet and clean up a broken unit tests with a smile and a little follow up friendly education. The TWikiSchool activities can hopefully assist on getting people better up to speed with this hard topic.

I could think that people that felt code was rejected may more have been bug reporters providing patches than people that have taken the task to actually get checkin rights. Maybe giving better feedback of why a patch is not brought into SVN is a good thing to do. I know I have been rejecting a specific patch that came through this route.

Code does not always get reverted directly. It may more get re-written without mercy months after. Maybe we can explain the code improvements we do to the original contributor. We may even get even better code at the end after a good dialog.

We need to watch out for IRC. We may be too open mouthed there when we comment code. I remember myself that I found some remarks very hard and it was only much later that I realized most hard comments are in reality developers commenting code they wrote themselves years earlier. But maybe new potential contributors do not realize this and think that it could be their code that get this verbal treatment. I think IRC is a vital recruitment tool.

There is development going on in branches in rare cases. I think we all ignore this to some degree. We may need to earlier give feedback to if what we see will have a chance to get merged back later.

Some features that are more complex and take weeks or months to stabilize have made the MAIN (now trunk) branch non-working in periods. This puts a mental and maybe also a practical block on less experienced contributors. I know that I personally do not touch the core code in periods where the engine does not run or runs with a lot of errors. The reason is that when you are less experienced a vital sign of having screwed up is that things stop working. When you work on a code base that is already not fully working it takes great self confidence to believe in your own code and assume that YOU did not break anything. The solution to this may be a conbination of checking in the first code of the long duration implementations a little later when they are more stable. Or to branch for a few weeks and merge back when things are stable.

I am trying to test some idea here and I do not feel certain that they will all work or that I am right in my assumptions. Does anything I said here make sense?

Sometimes new people are not aware of the group behind such a project and are simply overwhelmed by its dynamics. It remains a dive into the dark cold water to become a new contributor on any open source project of that size.

Message to the outer world: "Hey you newbie: there's light down here. Have a seat. It might not feel that comfortable at first but the tv program is very decent ... and you can even participate on the show."

I am guilty of having reverted code of a new contributor, and I am afraid I alienated him, as he did not come back with a better patch. However, his changes segfaulted perl, which isn't the fault of anyone of us. Still the guy went away. Or is he back? I think I was right to revert his
contribution in this case. Anybody on the project is a "living filter" on the shared code. That's important and works out quite well, as long
as things make progress.

I agree "have a seat" is important - low hanging fruit here is to give a more overwhelming welcome in the ".. would like to check in"-topics.

Alone the fact that we ask newcomers to fill out this kind of public form is a showstopper for some potential contributors. So that we - as a community - start to use these opportunities to exercise our friendly voices would be a great win. Usually these topics get 1-2, maybe 3 voices (on top, often by the same regulars :-/) - they should have the voice of more of us.

The topics are important because it is the first real "agreement" between the community and the contributor, and they are built in a phase were we have the luxury of the undivided attention of the new contributor - the more we can put in the basket at this point, the better.