[vlc-devel] Update on the VLC project

[Pierre Ynard]

I still want to add constructive remarks and answer who asked what I
had to suggest. When I was talking about a roadmap, I didn't mean
something very formal with set deadlines. I agree that just talking
about ongoing work, whether on a big board at the VDD or in an email
thread, would be enough.

Let us accept that we are not getting an organ for technical design. The
experience brought up by Rafaël is interesting. For reference (courtesy
of him):

http://daniel.haxx.se/blog/2011/03/09/first-time-for-steering-board/
http://www.rockbox.org/mail/archive/rockbox-dev-archive-2011-02/0068.shtml

I'll take two things out of it: it took them a "long time", to produce a
statement; and it seems that the issue was more about the development
process than the technical feature itself.

Also, it is called the Rockbox Steering Board; the term "steering" seems
to encompass more than sole "technical arbitration". Indeed, I think our
problem is broader than that, and I doubt that a technical arbitration
committee such as proposed would address it all. More precisely:

 - Eventually resolving the technical conflict: sure. I agree that it
   would help ensure that discussions are motivated by fair and honest
   arguments, and not by the selfish agenda of one developer. Also, as I
   mentioned earlier in more negative terms, it does bring more people
   to the discussion and prevents it from degenerating into something
   that will be felt as a one-vs-one feud, or an unworkable disagreement
   that will lead someone to quit.

 - Preventing violations of a fair development process (aforementioned
   in "a few unwanted actions"): pushing controversial changes, revert
   wars etc. As Rafaël said, maybe the mere existence of a committee
   would deter outright wrong behavior. But would judging process
   violations fall within the scope of this "technical arbitration" ?
   Are they completely non-technical issues that can be handled by the
   envisionned bad behavior sanctions? What about the occasional
   obnoxiously broken commit that breaks the build system, renders VLC
   unusable, annoys everyone and deters development? We don't want to
   wait weeks to let the "old wise men" gather and ponder on reverting
   it or not, leaving master broken meanwhile. And they probably don't
   want to be bothered just to revert a stupid commit either. It might
   work to unconditionally revert right away commits that make people
   whine, but that's not nice and that's how revert wars start. Until
   more is decided, I withhold my opinion.

 - Avoiding simple unfriendliness that damages the community: sometimes
   it goes fast, harsh replies can arise in 10-line IRC conversations or
   3-email threads. The big majority of small occurences is not going
   to make it to a committee or face sanctions, let alone in a timely
   fashion. I suggest that a couple people be mandated to facilitate a
   nice and constructive discussion in these cases. Nothing too formal,
   I may be wrong but being mandated as such could help people step in,
   when they might be afraid to and then choose to stay out of trouble;
   and it could give them more weight which would help prevent the
   protagonists from just ignoring them. Some people might say "we're
   technical people so we're not interested in implementing social
   solutions" but being technical shouldn't be an excuse for being a
   free-for-all of social awkwardness.

That's just a clarification of my previous thoughts.

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."