[Scummvm-devel] Retiring & good bye

[yotam barnoy]

Hey Max & everybody else

I'm really sorry that it came to this. I know that even though I've had much
less time to work on ScummVM recently, I still read the emails on the list
and I greatly appreciated your input to the project. Your voice was one of
rationality and consideration. It'll be a huge loss to the project to see
you go -- a loss that will not easily be filled (if at all).

I think the lesson here is that one of the most important element in a
project like ScummVM is the culture, or the social interfacing between team
members. Human psychology being what it is, people tend to ignore or be
passive with emails. They tend to be protective about their code. As another
(minor) personal example, I, for one, felt that I never blended into the
'clique' of the ScummVM team members. There's a certain elitism among the
heavy contributors that's perhaps deserved, but as a porter who currently
has very limited free time, I don't feel like I'm included as much, and
therefore I don't feel as 'safe' replying to -devel emails. It's not a
strong feeling and it's probably a silly one, but the psychology is probably
typical of a lot of the part-time contributors. Getting over these
psychological, cross-cultural and interpersonal gaps is one of the biggest
challenges of ScummVM (and probably any open source project) and it seems
like these are the things that have gotten you down. The list of comments
you just made should be posted to the wiki, and I hope we will be able to
learn from them in the future.

Good luck with your next endeavors,

Yotam


On Wed, Jun 22, 2011 at 1:01 PM, Max Horn <max at quendi.de> wrote:

> Hi folks,
>
> with this email I would like to announce that today I am retiring from my
> position as lead developer of ScummVM. I will also take an indefinite
> off-time from any development work; should I resume it, then in the form of
> pull requests.
>
> I had prepared a long rambling mail with my reasons to leave, but then
> deleted it. Instead, I thought I'd try to write down a long rambling list of
> some suggestions for rules that, if adhered to, would have removed many of
> the reasons why I am leaving this project. They are based on my real life
> experiences over the years. If I was staying with the project, I'd probably
> try to work with the team to turn this into a "Charta" or so, but I ain't.
>
>
> * Code reviews by others are a great boon and a gift from heaven. Accept
> them with joy. And try to provide it by yourself, in a friendly and
> constructive manner. But if something is really bad, don't wriggle around
> it, say it.
>
> * More strongly: Every dev *must* accept that his code may be questioned by
> others.
>
> * Always try to cooperate and be constructive. And assume others are trying
> to do so, too. So, write your code reviews like that. Conversely, when
> somebody reviews your code, stay friendly, and see if maybe they have a
> valid point.
>
> * This is not an acceptable excuse: "I know the code I committed is broken,
> but I plan to clean it up some other day".
> No. You should only commit code that you believe to be working. If you
> really must temporarily commit broken code, then add a big explanatory FIXME
> comment to it, maybe "#if 0" it. But with git there is almost never an
> excuse for that: Instead, use a branch on your personal fork for this stuff.
> And "some other day" might never come.
>
> (Side remark: I have countless times committed broken code, although
> usually not consciously. And I am deeply grateful for all the people who
> either just fixed my crap, or notified me so that I could fix it. I never
> ever want anybody to fear that notifying a developer about a problem might
> get them flamed.)
>
> * Continuing, this is not an acceptable excuse either: "Gee, leave me alone
> with your comments, I feel sick today / my mommy died / my dog ate my
> keyboard / I am not in the mood." You had the time to commit this stuff, so
> you better have the time to clean it up. Especially if you *knew* it was
> broken, but also in general. And I am very sorry for your personal tragedy
> (I really am), but that doesn't mean we can make exceptions for your code.
> If you can't fix it, just be honest and straight and tell us, and together
> we'll try to find a solution. Just don't be rude about it.
>
>
> * Don't *ever* tell anybody  "Why do you even care?" about X (where X might
> be an engine, a backend, the Windows installer, code on Common, etc.). To
> the contrary, try to motivate people (or, if necessary, select people based
> on their motivation) to care for as many parts of ScummVM as possible.
> Ideally all. Just because a person does not use X or work on X right now
> doesn't mean they should be slapped on their fingers for doing so.
>
>
> * By extension of all the above: No developer should be allowed to wall off
> his/her personal corner of the project which nobody else is allowed to
> touch. Not. Acceptable. Of course common sense applies; we are a
> meritocracy, and people who know most about something should usually have
> the first say. But by extension, it is the team leads who have the final
> word (I'll assume they'll try to listen to everybody and find a good
> consensus, but that's just not always possible). If you can't live with
> that, I am sorry. Deal with it.
>
> * If you think the team leads are making bad decisions and abusing their
> power, tell them so. Assuming the team didn't do a bad job, your team leads
> will carefully reflect on this. And if asked by the team, they will step
> down. You know, being project lead isn't just a joy ride, it's kind of a
> huge burden (Eugene for example is doing an *awesome* and very tiresome job
> with this release handling).
>
> * Being a member of the ScummVM Team is a privilege and an honor. Having
> your port or your engine made part of it is so, too. Conversely, having a
> good porter / engine author on the team also is an honor and a great boon to
> the project. Just don't forget, though, it goes both ways. So, it is *not*
> automatic that a proposed new engine or port should be merged. It must
> comply to our standards, and the author(s) must accept the judgement of the
> team. If you don't like what you hear, feel free go go boo-hoo and run to
> your mommy, but that's how it is.
>
> * Communication: Discussion on IRC are often valuable and useful, but a
> discussion on IRC alone only reaches a tiny fraction of all devs. So the
> majority of the team will not know what's going on. This also means you are
> only tapping a tiny fraction of our knowledge (so many times I read question
> on the IRC channel log that I could have easily answered in a second, yet
> the people there couldn't). So, if you care about something, you should
> consider bringing it up on -devel. This does not preclude or replace IRC
> discussions.
>
> * If you urgently want to talk to somebody: Don't wait for them to pop up
> on IRC. Use the ancient method of email.
>
> * If you perceive a problem: Tell people. And tell them by email. Maybe
> file a bug report / feature request. Chances are, you are not alone. Do this
> even if you can't work on the problem. If you don't point it out, maybe
> nobody will ever.
>
> This concerns bugs in our code just as well as shortcomings of our APIs,
> weird features, wrong documentation, missing documentation, anything.
>
> * It is not enough to discuss a problem with a (lead) dev in an IC priv
> chat. Be prepared for the dev to ask you to notify -devel / a tracker / Wiki
> TODO list about this. Unless you expect that dev to solve all problems for
> you on the spot... do you?
>
> * Don't be afraid of emailing -devel. Just do it!
>
>
>
> As for myself: I recently I was not being able to be an effective leader
> anymore, because I begin to feel that pointing out issues I perceived was
> too much of a hassle -- I felt that I'd just get silence, or a scolding for
> criticizing the hard work of somebody else, and the question why I was even
> caring? (Of course this was not at all always the case, but this *feeling*
> put a big damper on my motivation). Plus, I felt that "ah heck, if that's
> what they want to do, I shouldn't be a spoilsport." Indeed, I don't want to
> ruin anybody else's fun. Yet, if I behave like that, then I am *not* anymore
> acting like a good leader should. I was doing a bad job!
>
>
> And then I just care too much. And I feel too responsible for every aspect
> of ScummVM. That's not healthy. There is only so much I can do about various
> issues, and in many instances I'd need to rely on others to make the fixes,
> and if those others don't reply to my email, I just have to sit there and
> watch in frustration as things keep rotting. And it really doesn't matter to
> me *why* I don't get replies. First of, these others are of course entitled
> to their own private life, and to setting their own priorities! But: if
> their work on ScummVM isn't high enough up there, then I think it would be
> fair if they let us know about it. And we should then try to find others to
> help with the work, e.g on a port.
> Sadly, there isn't even anybody else around who is motivated enough to help
> with finding other interested people. Argh!
> And also sadly, I just can't make myself stop caring, so I just felt more
> and more frustrated with the state of various ports and engines.
>
> So, to protect myself, and also this project, I have to step down as
> leader, and get some distance from ScummVM.
>
> Despite all the negative things I felt recently, there are  still very many
> positive things about ScummVM. There are many highly talented developers
> working on it; people who as I write this are working on fixing all kinds of
> regressions on the 1.3.x branch and on master; who are working on cool
> improvements for ScummVM. Some very-well maintained ports; some great
> engines with active teams polishing them. There is a vibrant community that
> provides a lot of great feedback. The past 9 years were a great time, and it
> was fun working with many of you. I hope it'll stay fun for you, and that
> you'll have many successful years in front of you.
>
>
> Good luck to all of you,
> Max
>
>
> PS: I will unsubscribe from this list after sending this email, so if you
> need to contact me about any urgent matters, you'll have to email me
> directly.
>
> PPS: I still hold some ScummVM resources. E.g. some funds are on my
> account, and I currently pay for (using those funds) some webhosting, the
> scummvm.org domain name etc.. I will happily continue managing this stuff
> for the time being, since I don't want to let you sit in the rain by dumping
> all this on you without a prior warning.
> But of course I will also transfer any or all of it at the team's
> discretion at any time; just let me know. Likewise, if there are other
> things I may hold and you guys need, let me know (e.g. that gravatar account
> for the ScummVM github and stuff).
>
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is
> safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20110622/134a7eed/attachment.html>