[Scummvm-devel] Team Charter

Colin Snover scummvm-devel at zetafleet.com
Mon Jan 15 08:12:49 CET 2018


Hi Tarek,

I think this is a good idea. I have found on other projects that a short
document describing goals and expectations, which gets revised from time
to time, can do a lot to promote mutual understanding and give
transparency and confidence around the “why”s and “how”s of everything.
I hope I can provide useful feedback and that we can all come up with
something great together.

If I understand correctly what you are trying to do here, I think it is
important to communicate up front that making a bunch of changes is not
the goal here. Instead, the goal is simply to get an open conversation
going so we can actually figure these things out together and write them
down. Is this correct?

One thing I noticed is that the quoted email from Max seems to speak
more about a code of conduct than a direction. I think having guidelines
like these can be really valuable, and, based on the lack of response so
far (and my own feelings), I wonder if this is too big and overwhelming
to start with. Could you clarify what kind of specific feedback are you
looking for here, and when you would like it by? I also have a
suggestion for a place to start which may be more tractable, if you are
interested.

It would also be helpful for me if you have some examples of these sorts
of documents from other OSS projects which you feel are particularly
eloquent or useful in guiding this discussion. I would be interested in
seeing what others come up with too, if they know of any.

Thanks,

On 2018-01-09 19:23, Tarek Soliman wrote:
> Hi folks,
>
> I would like to propose that we codify a charter for the team.
> Let us come up with a document together that clarifies the team direction while
> establishing expectations, boundaries, etc.
>
> I've been looking for what is acceptable behavior for a team member and I ran
> across this old email from Max Horn [1]. It can be a good starting point for
> what I think should be a collaborative effort.
>
>> * 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!
> I am in full agreement with everything that's written here but it is by no
> means a final draft of what should be written down. I do think it should be
> eventually written down in the wiki or somewhere visible to new members.
>
> Please provide your feedback and suggestions, this is something we should come
> up with together.
>
> Thanks,
> Tarek
>
> [1]: http://lists.scummvm.org/pipermail/scummvm-devel/2011-June/009988.html
>
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.scummvm.org
> http://lists.scummvm.org/listinfo/scummvm-devel


-- 
Colin Snover
https://zetafleet.com





More information about the Scummvm-devel mailing list