[Scummvm-devel] Retiring & good bye

[Julien]

Hi!

I'm sad to see you go. In all of our interactions, you were always very
helpful and professional and your help reviewing code and pointing problems
was invaluable.

Thank you for all your hard work!

Julien

> -----Original Message-----
> From: Max Horn [mailto:max at quendi.de]
> Sent: Wednesday, June 22, 2011 6:02 AM
> To: scummvm-devel devel
> Subject: [Scummvm-devel] Retiring & good bye
> 
> 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