Feedback! Re: [MPlayer-dev-eng] Offer of help to get me started

[Struan Bartlett]

Dear MPlayer Development Team,

I like MPlayer and believe in it.

I first joined this list because I wanted to contribute to MPlayer what 
it didn't have, which I needed.

Because of some of the responses my contribution was given (you're about 
to find out) I lost interest.

By chance, I came back to the list today.

But when I saw again the kind of thing that made me drop out the first 
time, I felt so strongly that I decided I'd put my metaphorical pen to 
paper to tell you how I see it, for what it's worth.

The thing is, some of you on this list treated me with respect and made 
positive suggestions, without preconceptions or expectations about my 
abilities or intentions, for which I thank you.

But some of you treated me rudely, as if you were tyrannical rulers, as 
if you owned MPlayer, as if I was trespassing on your property, as if 
you feared for your position:

    You scorned my ideas, instead of trying to understand them.
    You disputed my needs, without concern for whether others had these 
needs too.
    You rubbished my coding style, although I had based my style and 
structure on what was already there.
    You criticised my implemention, although it was mostly harmless and 
caused fewer Segmentation Faults than approved code, without making 
positive and polite suggestions for improvement.

    You were full of your own preconceptions and expectations about my 
abilities, my intentions, and the needs of MPlayer's users.
    You were full of your own preconceptions and expectations about your 
own abilities and the quality of MPlayer's source code and documentation.

    You didn't make me feel welcome.

    It's like: "Aaaaah," you were saying to yourself, "another new guy 
has just barged in."

        "His ideas are different to mine.
            I don't get them. I know I'm clever, so he must be stupid. 
We don't want him here.

        His needs are different to mine.
            I don't get them. Addressing his needs threatens me getting 
what I want. We don't want him here.

        His coding style looks different to mine (does MPlayer have a 
coding style?)
            I don't get it. I can't read it. We don't want him here.

        His implemention is different to how I would do it.
            I don't get it. He doesn't speak my language. I'm busy 
coding what I need so I don't have the time to give his code thought.
            But I don't understand it and it might break. We don't want 
him here.

        He's getting in the way of what I know is right. MPlayer's gonna 
get out of control if we're not careful!
            I'm gonna have to get tough with this guy if I'm going to 
defend MPlayer and keep it safe."

        "You're not from around here, are you boy?"

    Sorry sir, no I'm not. ;-)

    Here's what I know about this kind of fearful, defensive, fighting, 
controlling response.

    It is traditionally found in stagnating hierarchies where, because 
of a lack of investment by the leaders in their capital's production 
capacity (perhaps there's a problem with delegation), growth in the 
number of positions is small. The people on each rung become overworked, 
fearful of additional demands on their time, and must compete fiercely 
for a limited number of positions on the next rung up.

    This response can also be seen in stagnating communities where, 
because of a lack of investment by the members in their capital's 
production capacity, resources become scarce. The members become 
defensive of their position, their territory. They become suspicious of 
newcomers, and exclusive about the group's membership.

    But by putting off newcomers and being closed to their ideas, this 
response accelerates the stagnation of the hierarchy or community.

    It is also wasteful, because newcomers must take their labour to 
another group, which results in there being two groups duplicating their 
efforts!

        In an open-source software project, this kind of "closed" 
behaviour gives "open-source" a bad name!!

On the contrary, it is by welcoming newcomers and their ideas, however 
alien they may seem at first; by trying to understand each other and 
reconcile their differing views, that a hierarchy or community will be 
invigorated and grow. Isn't this what we all really want for MPlayer?

To me, MPlayer's production capacity seems to be a function of the 
quality of at least four key kinds of capital:

    * source code: its readability, simplicity, elegance, bug-freeness, ...;
    * development guidelines: its readability, simplicity and concern
      for the health of the project as well as the enthusiasm of the
      developer, ...;
    * human: the number of developers, their level of intrinsic
      motivatation, their ability and carefulness (to program and
      communicate), their creativity, ...;
    * social: the developers' understanding of the project's purpose,
      vision, and values; the developers' understanding of each other
      (personally); the positive and constructive nature of their
      interactions, ...

I can see there's scope for investment and room for improvement, with 
regard to most of these areas of production capacity.

I realise we're all working really hard and it can feel like we don't 
have enough time, but in the long-term it's counterproductive to focus 
on production at the expense of production capacity - take a break for a 
moment and think about it.

For example, what's more important?

With the Aim of Growing MPlayer's Production /
 So You Can Get On With Your Own Work /
For the Sake of an Easy Life
	With the Aim of Growing MPlayer's Production Capacity /
Investing in its Future Success
Defending your own coding style, at the expense of bringing new 
developers on-board
	Finding a new one that you're still happy with that helps bring more 
new people on board
Ignoring fighting on the list 	Addressing it to ensure avoiding two good 
developers being lost in the fall-out
Slagging off a developer's abilities, at the expense of losing a 
competent developer
	Expressing your specific concerns and trying to reach an understanding /
Or, expressing your general concerns, apologising for not having the 
time to help but
pointing them in the direction of someone else who can


Less fear. More peace.

Looking forward to reading any considered responses,

Struan.

kosh wrote:

>>If someone is so new to C that spacing prevents them from reading
>>code, they'll introduce more bugs than they're worth...
>>    
>>
>
>It's not about preventing people from reading the code, it's about
>putting an artificial barrier in front of people who might want to help,
>but dont want to wade through badly formatted code which is hard to
>comprehend without a lot of aspirin.  
>
>  
>
>>>I suppose what I'm essentially saying here, is that everyone can read
>>>the alphabet, but it only becomes legible or useful, when those letters
>>>are put together in a structured, well understood manner.  a jumble of
>>>letters according to each developer how they like it, is harder to
>>>read.  Even if the end decoded product makes sense to people.
>>>      
>>>
>>Please stop trying to argue by analogy. This is a classic fallacy and
>>almost always makes one look like a fool, especially when the analogy
>>is bad like here.
>>    
>>
>
>Well I thought an analogy would help you understand what I was trying to
>say.  I dont think analogies are bad.  I think throwing abusive
>statements at people you dont know say more about the person doing the
>throwing, than the person doing the recieving.
>
>  
>
>>>>That's nice. I agree totally wi
>>>>

>>>>th Linux's style and use it myself, but
>>>>I disagree totally with trying to reformat everyone's code to meet
>>>>some arbitrary standard like that.
>>>>        
>>>>
>>>well this is what I find hard to understand.  You agree with linux's
>>>style, yet you dont think it's right that the code should undergo a
>>>reformat to meet an agreed style.  At one point, the linux code
>>>underwent this change too and like you said, you totally agreed with
>>>      
>>>
>>No. By agree I mean I find the style visually pleasing and use it
>>myself almost exactly. Nothing to do with imposing it on anyone.
>>
>>BTW, lots of Linux is *not* in Linus's coding style!!
>>    
>>
>
>Then you shouldnt really have any problem with seeing the entire
>codebase in that similar style, should you?  Also the linux kernels
>style, used by linus too, is because he bent a little and wasnt so hard
>nosed about his style that he couldnt compromise with people for the
>better good of the project.
>
>  
>
>>>as for the professional part of what I said.  I'm more talking about
>>>coding in a professional frame of mind, as opposed to coding in a
>>>professional manner.  What I mean by that is that you, for the good of
>>>the dev team, agree on a style by which everyone understands and
>>>implements.  You eliminate the aspect of reading the code whereby you
>>>have to decode the style first, then only can you understand the code. 
>>>Of course any competent C coder can do this, but why should they? just
>>>to be leet?
>>>      
>>>
>>I don't have to decode any of it because I'm competent at reading C.
>>Apparently you are not.
>>    
>>
>
>Again, with the insults.  However, since you dont know me, I find it
>hard how you can make such a statement.  I have been writing C code,
>along with C++ code for around 7 years.
>
>  
>
>>The general impression I get is that you're a CS student who's never
>>written a real program and just took a "Software Engineering" course,
>>and decided to go try to apply all that dogmatic nonsense to someone
>>else's project.
>>    
>>
>
>Then I guess I should inform you of your error.
>
>  
>
>>Even if you ideas were good, it is socially inept of you to barge into
>>the list totally unknown and tell everyone you want to make a sweeping
>>change like this that is explicitly forbidden in the documentation
>>(DOCS/tech/patches.txt). At the very least you should already be a
>>respected contributor who's proved his worth through useful code
>>before proposing that we bend over backwards to do things you way.
>>    
>>
>
>I made the offer because it's the first thing that came to mind, the
>total uncoordination made me think that offering to clean it up would
>help you and help anyone in my position.
>
>  
>
>>Anyway, what sort of improvements to you actually plan to work on?
>>MPlayer is rather modular these days, so if you just want to write new
>>a/v filters or drivers, subtitle loaders, demuxers, etc. then you
>>*don't* need to understand the core that you were trying to reformat
>>whatsoever. If you actually plan to make large rewrites to the core to
>>address some of its problems (which I doubt, since I seems you have
>>not read the list in the past, so you probably don't even know what
>>its problems are), then proposing a reformat of the relevant files
>>would be reasonable, but still a topic open to debate.
>>
>>    
>>
>>>i dont think it costs flexibility at all.  If by what you mean it tells
>>>people to code in a certain way, instead of any old fashion then yeah, I
>>>guess it does.  But when projects get bigger and bigger, you have to
>>>lose flexibility in a tradeoff with comprehension.
>>>      
>>>
>>No. Quit this nonsense argument. Comprehension is not affected by
>>spacing since you can change it any-which-way you like with the indent
>>program in your local copy.
>>    
>>
>
>It's not a nonsense arguement, it's 100% correct, comprehension IS
>affected by badly formatting code, anyone who says otherwise is either
>ignorant or stupid.  Of course, spending time to decode the code into
>something that makes sense takes time therefore affecting how much code
>you can comprehend at any one time.  Jees, this isnt rocket science.
>(I'm not making any friends with that statement, but right now, I'm
>thinking I dont care that much)
>
>There are statements in the code which indent CANNOT fix, let me give
>you an example, case statements.
>
>case something:{
>
>}break;
>
>case something:{
>break;
>}
>
>indent going to fix that is it? no, I didnt think so.
>
>  
>
>>>all using different styles to code and the code as a result is hard to
>>>read.  I'm offering to solve that and all it takes is for people to put
>>>away their hacker spirit for a second and talk about it.  I know people
>>>here must be reading this thinking "oh man, you mean I have to change my
>>>style, f**k that".  But as competent C coders you are all capable of
>>>logical, reasoned thought.  A single style for the whole mplayer
>>>codebase would make the code easier to read for new people and eliminate
>>>a entire decode layer in comprehending the code.  How can that be a bad
>>>thing?
>>>      
>>>
>>No. Becoming familiar with the code *is* difficult (believe me, it
>>took me a long time!!) but it had nothing to do with indention and
>>layout. There are other stylistic matters that *can* affect
>>comprehension (variable and function naming, reliance on lots of
>>external/global variables, etc.), but that's another matter entirely.
>>    
>>
>
>You think that badly formatted code has no affect on the ability for a
>new person to come along and start helping?  Sorry, but thats stupidity
>talking.  If the code is hard to read and therefore hard to comprehend. 
>It will take longer for ANYONE to start contributing.  I dont care who
>you are, it's got nothing to do with your coding ability, but everything
>to do with mental comprehension.  Which is the same regardless of how
>good a coder you are. 
>
>  
>
>>>>If you want to *help* with the project, then write useful code that
>>>>does something. Reformatting to try to 'beautify' the source is not
>>>>coding, it's just a huge waste of time. Like Arpi has said, there are
>>>>programs that can do that for you. If you are simply unable to read
>>>>the source as it is (most likely this means you have a broken text
>>>>editor with tabwidth!=8), then reformat your local copy with the
>>>>indent program while working on it.
>>>>        
>>>>
>>>reformatting the code is what I think the source needs.  I'd like to
>>>      
>>>
>>Well then you're not what we need.
>>
>>What MPlayer needs is people to:
>>
>>o Fix bugs
>>o Reverse engineer and implement codecs and demuxers
>>o Fix dvd-nav support (I don't like it but lots of users want it)
>>o Optimize even more for speed :))
>>o Write more audio and video filters
>>o Rev eng and write drivers for more video cards
>>o Etc...?
>>
>>If all you can do is act as a slow human computer that runs the
>>"indent" program on your wetware (i.e. brain), I don't see how you're
>>helping us.
>>    
>>
>
>I'm not doing this to help "you" exactly, I'm doing this, or proposing
>this, in order to help others who want to help out, but can't or wont,
>because the code is a mess.
>
>  
>
>>>Arpi is right, there are programs which can reformat code, but you
>>>usually have to do it on new incoming code and they dont tend to work
>>>well with massive codebases like mplayer.  There are parts of the
>>>codebase which I dont think automated programs like indent would be able
>>>to reformat.  
>>>      
>>>
>>Then why don't you try it and see?
>>    
>>
>
>See what I said above about indent and you'll no doubt understand that I
>have tried it already
>
>  
>
>>>was only him doing the work, but as everyone can now see, as the
>>>codebase has grown enormously, a style is starting to become needed
>>>(just like what happened with the linux kernel, when it started to
>>>      
>>>
>>Linux is a kernel, so stop saying "the linux kernel". It sounds really
>>dumb.
>>    
>>
>
>I dont think it's dumb, I think it's sad that you resort to insults in
>what was a perfectly resonable conversation, but I am starting to think
>this is why MPlayerXP started.
>
>  
>