KDE/kdebase/workspace/plasma/applets/tasks (silent)

[Sebastian Sauer]

On Tuesday 05 February 2008, Aaron J. Seigo wrote:
> * free-for-all does have a very negative impact on the code base. we tried
> that, and we moved to peer review because of what that resulted in.

It also has positive advantages like quit a lot of commits, like feeling of 
beeing an important part within the process and like working together with 
everybody else on the same codebase in real-time.

My reply from Feb, 01 where I answered to the question "did you get this stuff 
reviewed before committing?" with "you can review it now." wasn't meaned to 
be sarcastic but just how I worked in KDE last 5 years. That means, first 
commit and then review (your own commits and the commits of others) and imho 
it was working quit well that way through I agree it's far away from beeing 
optimal.

> 1. how do we ballance keeping the code base functioning with keeping a
> happy community of hackers. how much can we trade off the former for the
> latter? what to do when someone says, "no, i will not adopt your project's
> workflow."?

I would say, that to push workflows on developers is a mistake. This should be 
done on a tech-level without changing the way developers work.

Joel once wrote a nice blog-entry about what he described with "beeing in the 
zone". That is this time a developer got really productive and pushes code 
out in an incredible speed. It is imho very important to don't block this 
phase with time somebody has to wait to continue or even with the requirment 
to write mail in between or something like this. It is difficult enough to 
get into that phase and it's very easy to be pushed out of it again (one of 
the reasons why I am not at irc during that time since each ping would take 
me out of it).

Also it is just not needed since this can be done at a technical level with 
the right tools and it even provides more advantages like beeing able to 
switch between "working-branches not in trunk yet", like even working on 
things incremental that just are not ready yet for mainline or like beeing 
able to continue work offline.

> 2. how to keep development as friction-free as possible: it should be fast
> and easy to work on the code base so we can keep a fun, enjoyable and fast
> pace. again, this needs to be ballanced with the "healthy code base".

++
through I guess the kernel-devels didn't solved this 100% too yet ;)

> it's not an easy ballancing act for me, to be honest, and i'm looking for
> feedback and input. on saturday we'll be discussing whether to keep
> review-board or not, for instance. is it helping or hindering development?
> is it useful or just a pain? etc...

oh, it can be a quit useful thing. E.g. myself would land his work to turn 
the "configure desktop" dialog into a kcm there (nah, far away from beeing 
ready or usuable yet) since it just touches lot of code and review would be 
more then welcome there.
It's just the case that a "each commit needs to go through a webbased board 
and you have to wait some time till somebody says ok" solution just is 
overhead++ imho.

> i'd also *love* to have an effective way of saying, "working on plasma
> means working with the rest of us." that doesn't piss people off. or maybe
> it's just not possible because some people don't want to work in a team,
> which is obvoiusly one valid way of writing code.

heh. Maybe we define teamwork and review different here. But if I look at the 
commit somebody else did land, it's a review. If I extend the code somebody 
else wrote, it's teamwork.
To try to do all this in parallel is imho just not possible cause we are still 
developers from all over the world and just don't work at the same time at 
the same piece of code.

> > Else I'll just to anything to block that negativ energy.
>
> is there a way you can wave a red flag to say, "this is hurting my
> motivation" that doesn't include, "no, i won't do it that way. it's my way
> or i leave."? because dealing with those sorts of reactions really hurts
> other people's motivation (and not just mine, btw)

well, let's look at the intro you wrote at your mail to me from Feb, 02;

"your commits in this case have become increasingly wrong, revision by 
revision. you're not actually working faster, you're just working wronger"

this is just 0% information with 100% flame imho. You could have sayed the 
same in nicer words and maybe even more explicit with a concret sample. This 
wouldn't only provide a better feeling and a direct prove including a 
learning-lesson how to do it better but also shows why a review would be 
needed here.

Unfortunately with the wordings above the result is the opposite of what you 
tried to achieve there and for sure that didn't provide you a good feeling 
too :-(

> > What I tried to outline (maybe not clear enough) is, that I don't
> > believe that it's a good idea to prevent commits.
>
> i understand that; that's the whole "development friction due to process to
> ensure quality" thing. it also sucks that every so often i'm out of the
> country. i've actually pulled back on my travel in part to be able to avoid
> that, btw. more ballancing acts =) it was highly discouraging that i should
> be in intermittent contact for a week and have so much go sidewise during
> that time. there was a lot of *good* stuff committed too. that's really the
> challenge, right: how to filter in the good stuff, and weed out the couple
> of not good things.

guess thereis just no way to be really sure that no regressions or new bugs 
will land. But as long as ppl to review and fix that bugs again and as long 
as the frequency new bugs land is lower then the frequency bugs got 
fixed... ;)

but, yes. It's a problem without proper solution :-/

> remember as well that every step backwards that gets taken usually ends up
> on my plate to make up for. few others who are doing this as a sideline
> hobby are willing to do that. this is the same thing as with kicker, right?

y, I know what that feels like. Sometimes it's really frustrating to see that 
again something got broken that was working well just the day before. Then 
it's needed to fix it rather then to get it into the same state like 
yesterday what feels like, well, no progress with lost time :-/

On the other hand there are also those moments where it's great somebody did 
land something that just works and that was on the todo anyway. This are 
the "wow"-moments where FOSS just shines.

I guess it helps there a bit if you see yourself as teacher and mentor. With 
every wrong commit you are able to fix, you will also earn the possibility to 
teach someone how to do it better. And with the time your students will 
learn, will do it better, increase there quality and maybe even start to 
teach by themself...

> back then (and i was still a volunteer, so this isn't related to me getting
> paid to do it) i took on the job of protecting the quality of an already
> fragile and completely neglected code base. it's what i do, some
> personality flaw/quirk ;) so this isn't a zero sum game: when i don't
> manage to weed out the smaller bad things, i end up spending time i'd
> rather spend moving things forward working on keeping the house in order.

and I am pretty sure you also learned over the time just like me did and the 
quality of your commits just increased over the time. Probably also by doing 
mistakes and by being teached by someone how to do it better. I guess that's 
a very important process and something FOSS pays back to there developers. 
Those experiences are just in no way affordable and one of the reasons why 
FOSS-developers are the better developers :)

> > Please understand that
> > this is a _plain_ technical issue since subversion just does not allow
> > such workflows without sucking the one (those who commits) or the other
> > (those who likes to review).
>
> realize that this was also an issue of just plain ignoring the stated
> design goals. it wasn't even a "oops, that patch was buggy" this was "that
> commit goes against the design principles" combined with "someone else
> already had done this work, but apparently this wasn't communicated clearly
> to everyone else and so people duplicated efforts."

Guess I still don't got that point about "design principles". Is it those 
GUI-dialog? Well, that was really only 5% of the work (in terms of time that 
was needed till it was working).

I guess that is pretty much the same like with my i18n-commits. I know, that 
my english sucks since I learned english over the internet in 
FOSS-communities, but that doesn't prevent me from committing also 
i18n-strings since it's the same princip; better at least something that 
works somehow is in. Somebody will extend it later anyway just like I extend 
the work others did.

> > > obviously, whatever you decide to do with your time is your decision.
> > > it'd just be nice if the alternative to "i want to work without
> > > communicating" was not "i'm going away". i hope you eventually
> > > reconsider your reaction.
> >
> > ok, I did (reconsider),
>
> yes, when i saw your commit earlier today i smiled and sighed a bit of
> relief. it does pain me whenever someone isn't happy. again, another one of
> my stupid personality flaws. =)

I was btw also pissed I saw that somebody else did broke it and my first 
intention was to just revert the whole commit. But I got over that initial 
feeling and then just tried to fix it + provide feedback why it is wrong. 
Well, teaching can really provide fun too :)