Meeting scheduling and openness
L. David Baron
in dev-planning about meeting scheduling that was a subthread of the
thread "Security review of Cross Site XMLHttpRequest":
http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/fe118aaf497e961b/
While I can't speak for why some of the other people objected so
strongly to the rules Gerv was proposing for meeting scheduling, the
fundamental reason I objected so insistently is that I think
openness is good. Openness allows more people to get involved in
the project -- people we might not already know about. Openness
allows new contributors to figure things out for themselves and then
do useful work. (Figuring things out for themselves is good,
because it's often not worth the time to teach anybody who comes by
to ask questions, since most of them will just go away anyway.)
I am concerned that whenever somebody does something more in the
open, they get attacked for not also being more democratic, by
people who I think (to present the position in its extreme form)
want Mozilla to change from a loosly governed meritocracy to a
strictly-governed democracy where anybody who wants to vote can do
so. But open source projects fundamentally aren't democracies. If
you force the people who do the work and have the knowledge about
the code to listen to those who don't, they'll just take the code
elsewhere and do what they were doing before. That's the
fundamental nature of open-source -- it's forkable. And successful
open-source projects should often be governed so as to minimize
forking -- at least to minimize forking by the people who do the
work and have the knowledge of the code (since forking by others
really just means maintaining a few side patches).
Let me repeat: Mozilla will never be governed by a system giving
one vote to whoever wants to speak up. It simply won't work.
I think the criticism for not being democratic enough of those who
do things in the open will make the project more closed, and I'd
rather see us become more open. I think I and others often avoid
doing things in the open for fear of having to:
* waste time arguing with people who believe they have a right to
be involved in our decision making
* worry that starting a discussion in the open will cause other
developers to waste time answering questions who feel they have
the right to demand explanations of anything they don't
understand in the discussion (frequently followed up by equally
uninformed replies)
And I fully realize that doing so cuts off the way I became a
participant in the project -- but I just haven't had the energy to
fight it (until now, anyway). Right now, if I want to ask bzbarsky
and roc for their opinion on something that I think is only worth
five minutes of consideration, I send private email or ask on IRC
(which is not usefully public), because if I posted to a public
list, I and others would spend an hour dealing with the unnecessary
replies (and, often, correcting the misinformation in them). (I
actually tried that about six months ago, and that was my feeling of
what happened.) So we lose the benefit of having others see the
discussion.
I don't want to spend all our energy oiling squeaky wheels. I'd
rather encourage contributors who have the drive to figure things
out for themselves. Mozilla is not governed by the principle of one
squeaky wheel, one vote.
What does this mean about meeting scheduling? It means I'm strongly
opposed to rules that require meetings be scheduled in certain ways.
Such rules would just make people call fewer things "meetings" and
make the project less open. Doing things where the person who
enforces the rules on scheduling meetings can't see them means doing
them where potential contributors can't see them.
-David
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation
Gervase Markham
> While I can't speak for why some of the other people objected so
> strongly to the rules Gerv was proposing for meeting scheduling, the
> fundamental reason I objected so insistently is that I think
> openness is good.
Looks like we agree on the goal, then, which is good :-)
> I am concerned that whenever somebody does something more in the
> open, they get attacked for not also being more democratic, by
> people who I think (to present the position in its extreme form)
> want Mozilla to change from a loosly governed meritocracy to a
> strictly-governed democracy where anybody who wants to vote can do
> so. But open source projects fundamentally aren't democracies.
Just to be absolutely clear: I am fully behind the fact that the Mozilla
project is a meritocracy. I don't believe we should decide when meetings
happen, or almost anything else in the day-to-day running of the project
for that matter, by voting on it.
My argument in this particular case were twofold. The first was: "If
it's just as easy to have the meeting at 11am as at 3pm, please can we
have it at 11am?" In response, several people pointed out why sometimes
it's not easy to have meetings at 11am - which is absolutely fair
enough. But sometimes it is.
The second was: "Can we make it more obvious that meeting time proposals
are not set in stone, and project contributors should not feel they are
being awkward if they ask for a change to fit better with their
schedule?" I still think that making this clear is a good thing.
> I think I and others often avoid
> doing things in the open for fear of having to:
> * waste time arguing with people who believe they have a right to
> be involved in our decision making
> * worry that starting a discussion in the open will cause other
> developers to waste time answering questions who feel they have
> the right to demand explanations of anything they don't
> understand in the discussion (frequently followed up by equally
> uninformed replies)
I believe such interactions are often referred to as "bikeshed
discussions". Mitchell and others also talk about "stop energy".
I won't deny that having conversations in the open is more effort than
having them in private. And it's difficult because the benefits of
having them in the open are normally non-tangible and accrue over the
long term (better transparency, better records of decisions, it's easier
for other people to feel involved and get involved) whereas the benefits
of asking on IRC instead are that I get a quick answer right now and can
get on with my code to meet the release deadline.
Can we find some way to have discussions in public without falling prey
to these issues? Some projects use moderated or read-only mailing lists;
but that just takes up contributor time in a different way.
Is simply ignoring such people a possibility, or would you feel guilty
about doing so?
> What does this mean about meeting scheduling? It means I'm strongly
> opposed to rules that require meetings be scheduled in certain ways.
I am as well. I was only asking for the "default meeting time" to be one
which covered the greatest number of contributors.
Gerv
Iang
> I wanted to follow up here on a bit of the discussion in the thread
> in dev-planning about meeting scheduling that was a subthread of the
> thread "Security review of Cross Site XMLHttpRequest":
> http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/fe118aaf497e961b/
To look at that particular thread of the meeting discussion
(a very common problem):
1. The guy that set the meeting did no bad thing, and the
call for a better time was no bad thing, either. It should
have IMHO been a. acknowledged, and b. rejected, c. politely.
2. Shifting the time means losing some people, and not
shifting the time means losing some, too! Talking about it
also means losing people, practically everything means
losing, except coding ;-)
3. At the end of the day, all meetings are compromises!
4. Therefore, someone should have final say. If no-one
is "manager" then it is by default the guy who starts the
meeting. Respect that guy's decision, his job is hard
enough without others trying to micromanage or fine tune.
5. The meeting is judged on its results, not how many
people show or how many people "call for votes."
6. There's *always* a next time.
7. So don't change the plan. Acknowledge the mistake and
move on. Fix it next time.
In general, unless there is a real bad conflict such as a
key contributer who can't make it, it is better to say "My
bad, the meeting time stays the same, but I'll try and do
better next time." Try and stick to the original plan, and
acknowledge its weaknesses. Shifting always costs, sticking
wins more often than not.
iang
Jean-Marc Desperrier
> L. David Baron wrote:
>> I think I and others often avoid
>> doing things in the open for fear of having to:
>> * waste time arguing with people who believe they have a right to
>> be involved in our decision making
>> * worry that starting a discussion in the open will cause other
>> developers to waste time answering questions who feel they have
>> the right to demand explanations of anything they don't
>> understand in the discussion (frequently followed up by equally
>> uninformed replies)
> Can we find some way to have discussions in public without falling prey
> to these issues? Some projects use moderated or read-only mailing lists;
> but that just takes up contributor time in a different way.
Why would read-only mailing list take up contributor time ? I think they
could be a good solution.
When David needs to ask roc and/or bzbarsky for their opinion on
something, I think in almost 100% of cases there will later on be an
occasion where reading it would help someone figure out by himself why
things have been done this or that way. And maybe often help David, roc
or bzbarsky themselves remember why they did things that way.
Also if I, as an external contributor, read something on that read-only
ml about I am able to say something pertinent and argumented, I am
certain that I will be able to find another channel to make my voice
heard about it.
I find it strange that David finds irc is so protected from public
disturbance, as opposed to ... mailing-lists, usenet groups ?
Maybe the protection is that on irc there's only a short time windows of
opportunity to interfere with a discussion. But I have always found the
downside huge, and I'm surprised that regulars on irc don't find
themselves always answering the same questions.
So would not also an easy solution to make discussions more open,
without changing the habits, to archive irc exchanges (like on
http://bugzilla.glob.com.au/irc/) *and* make sure it's indexed by Google ?
On the subject of openness, one other thing I would find interesting is
if it were easier to see externally what subjects the mozilla workforce
is currently concentrating on, and what are the subjects it would like
to develop but doesn't have the resource to.
Iang
> I am concerned that whenever somebody does something more in the
> open, they get attacked for not also being more democratic, by
> people who I think (to present the position in its extreme form)
> want Mozilla to change from a loosly governed meritocracy to a
> strictly-governed democracy where anybody who wants to vote can do
> so.
On the wider, macro-level topics raised in your post
(non-meeting related).
Democracy ==> Voice ==> Acknowledgement ==> Judgement calls.
I think there is a persistent misunderstanding about what is
meant by a democracy ... it is silly to expect "everyone to
have a vote" ... rather, people are using the word democracy
to indicate that everyone can have and maybe should have a
voice.
It is the spirit of democracy not the implementation that is
intended.
> Let me repeat: Mozilla will never be governed by a system giving
> one vote to whoever wants to speak up. It simply won't work.
Yes that won't work.
The problem is people express their opinion ... raise their
voices ... and are not able to make their case. (Shucks!)
Sometimes they turn out to be right, and the people "in
control" turn out to be wrong. (Bummer!)
Or, to put it more politely, the squeaky wheels can be
indicative of needing a little oil, *or* they can also be
indicative of needing major maintenance needs.
In at least one area I know of, this happened, and Mozilla
has now lost years and is trying to catch up. For the sake
of some missing timely maintenance, you now have a complete
rebuild to do.
So the question you have to ask is whether you want these
people to gradually become more isolated, rejected and
pushed outside the walls & moat of Castle Mozilla, and
finally leave, concluding that getting a voice heard is
impractical or impossible...
OR...
Whether there is some middle ground that keeps the squeaky
wheels around until you finally figure out what those
squeaks really mean? And you need to hear them.
The democracy language reflects that difficulty, and should
not be interpreted literally as "I want a vote," rather that
"I want a voice!"
The middle ground, or cutting the gordian knot, is simply
acknowledging the voice, and being brave enough to say "No."
The squeak in the wheel is really saying
"I want my voice to be acknowledged.
I want to be told that I have been
listened to, and someone has made a
judgement call to *not* adopt that
at the present time.
So I can stop wasting my time."
If you don't say "No." then they don't know whether you
heard, or whether you agreed or whether you disagreed. So
they will keep trying, annoy you more, and then get pissed off.
The way to deal with squeaky wheels is for you to come up
front and say "I hear, I don't agree, and I declare that I'm
not going to do that. It's my call and I'm making it."
Then, both sides can *honestly, fairly* wait and see who wins.
(The one who was wrong is the one who wins, because the
prize is the learning opportunity. There's no prize in
being right :-)
> I don't want to spend all our energy oiling squeaky wheels. I'd
> rather encourage contributors who have the drive to figure things
> out for themselves. Mozilla is not governed by the principle of one
> squeaky wheel, one vote.
Now time for a squeaky wheel :) What IMHO is missing
frequently in such conversations is that there are many
people who can contribute, but do not code.
To me, "have the drive to figure it out" is shared
understanding (secret-code-language) for "can write code."
Currently, Mozilla custom is as if the only contribution
that counts is code. Anything else tends to be thrown in
the bucket of squeaky wheels.
Yes, many problems require serious (non-coding) skills.
(Like the posted thread.) That means meetings. And
conflicts. Arguments, consensus, documents, white papers,
conferences, evidence, internal PR, decisions, judgement
calls, etc.
Developers aren't good at these things; they are by
definition good at developing code.
So when you hit these issues, the thing that is missing is
that Mozilla is now far too large such that all problems are
solved by code. Or by developers.
Your response of being forced into non-openness is very
rational and useful ... and it will solve the coding
problems ... but it won't solve the wider problems that Gerv
is pointing to.
> What does this mean about meeting scheduling? It means I'm strongly
> opposed to rules that require meetings be scheduled in certain ways.
> Such rules would just make people call fewer things "meetings" and
> make the project less open. Doing things where the person who
> enforces the rules on scheduling meetings can't see them means doing
> them where potential contributors can't see them.
OK, back to the micro-scale of that particular thread: I
agree. You call a meeting, you set the time. If someone
says that's not good enough, respond with acknowledgement,
but try and stick to your plan, unless it is a disaster.
"I'm making a judgement call not to follow that, although I
see the merit in it. Next time, I'll do better."
All in the opinion of this not-so-humble despot, that is :)
iang
Mitchell Baker
[snip]
>
> On the subject of openness, one other thing I would find interesting is
> if it were easier to see externally what subjects the mozilla workforce
> is currently concentrating on, and what are the subjects it would like
> to develop but doesn't have the resource to.
On the very detailed side it's possible to find out what people are
working on -- the product plans and bugs and so on are available.
But of course, this doesn't address the overall picture -- what areas or
directions or technology goals will be the focus of activity for the
foundation workforce (including corporation employees) and what areas
won't? And why?
I think it's my responsibility to articulate current thinking better. I
will try to do so shortly. I'm traveling for a week and am unlikely to
get a lot of writing done, but will aim to do so shortly after I return.
Mitchell
Gervase Markham
> Gervase Markham wrote:
>> Can we find some way to have discussions in public without falling
>> prey to these issues? Some projects use moderated or read-only mailing
>> lists; but that just takes up contributor time in a different way.
>
> Why would read-only mailing list take up contributor time ? I think they
> could be a good solution.
That part of the sentence was supposed to apply only to "moderated";
sorry if that wasn't clear.
> I find it strange that David finds irc is so protected from public
> disturbance, as opposed to ... mailing-lists, usenet groups ?
I think he means IRC private messages.
> So would not also an easy solution to make discussions more open,
> without changing the habits, to archive irc exchanges (like on
> http://bugzilla.glob.com.au/irc/) *and* make sure it's indexed by Google ?
That would be good, but I don't think it would solve the problem
(because it wouldn't capture private IRC discussion, and because the
volume and lack of structure means IRC transcripts aren't a very good
place to store information.)
> On the subject of openness, one other thing I would find interesting is
> if it were easier to see externally what subjects the mozilla workforce
> is currently concentrating on, and what are the subjects it would like
> to develop but doesn't have the resource to.
See Mitchell's reply on this. I've started posting statuses on my blog;
I would encourage others to do so as well.
Gerv
L. David Baron
> Jean-Marc Desperrier wrote:
> >I find it strange that David finds irc is so protected from public
> >disturbance, as opposed to ... mailing-lists, usenet groups ?
>
> I think he means IRC private messages.
I actually meant conversations on public channels on irc.mozilla.org.
I think people are generally more polite on IRC both because it's
more similar to face-to-face interaction than email and because the
set of people on Mozilla's IRC is more biased towards core people
who understand the community.
But IRC is real-time, so it's hard for others to get involved if
they're not right there at the moment, and it's generally not
usefully archived or available for others to read.
Robert Sayre
> I think I and others often avoid doing things in the open for fear of
> having to:
> * waste time arguing with people who believe they have a right to
> be involved in our decision making
> * worry that starting a discussion in the open will cause other
> developers to waste time answering questions who feel they have
> the right to demand explanations of anything they don't
> understand in the discussion (frequently followed up by equally
> uninformed replies)
>
Having observed recent traffic on some of our more technical and
specialized mailing lists, like the layout list, I think your fear is
justified. We can't expect our busiest contributors to spend time
answering basic CSS questions.
I think the answer is to make those groups read-only for casual
participants, but do it in a way that does not totally remove the
ability of anyone on the planet to join the conversation.
I'll use a hypothetical layout group to illustrate. My suggestion is as
follows:
Create a read-only newsgroup called the "Mozilla Layout Blog", and use
the feeds from Google Groups to drive blog software. Then, make it clear
that it is possible to participate by commenting on the blog entries or
linking to them from your own blog. Perhaps a digest of comments
received on the blog could be posted to the newsgroup every few days. I
think this would be a great way to remove the noise, and it publishes
the same information in a bunch of ways, so it's not hard to find.
Just a thought.
-Rob
Robert Sayre
> I think I and others often avoid doing things in the open for fear of
> having to:
> * waste time arguing with people who believe they have a right to
> be involved in our decision making
> * worry that starting a discussion in the open will cause other
> developers to waste time answering questions who feel they have
> the right to demand explanations of anything they don't
> understand in the discussion (frequently followed up by equally
> uninformed replies)
>
Having observed recent traffic on some of our more technical and
Gervase Markham
> Having observed recent traffic on some of our more technical and
> specialized mailing lists, like the layout list, I think your fear is
> justified. We can't expect our busiest contributors to spend time
> answering basic CSS questions.
If basic CSS questions are making it through to these lists and groups,
when they shouldn't be, we need to fix that. Although I'm sure we had a
discussion about the separation of web-dev and dev and decided to merge
the groups. Didn't we? Maybe David was dissenting on that occasion.
> I think the answer is to make those groups read-only for casual
> participants, but do it in a way that does not totally remove the
> ability of anyone on the planet to join the conversation.
I'm not sure this is technically possible for newsgroups.
> I'll use a hypothetical layout group to illustrate. My suggestion is as
> follows:
>
> Create a read-only newsgroup called the "Mozilla Layout Blog", and use
> the feeds from Google Groups to drive blog software. Then, make it clear
> that it is possible to participate by commenting on the blog entries or
> linking to them from your own blog. Perhaps a digest of comments
> received on the blog could be posted to the newsgroup every few days.
This runs into the "makes more work" problem, doesn't it?
Gerv
Michael Lefevre
[snip]
>
> Having observed recent traffic on some of our more technical and
> specialized mailing lists, like the layout list, I think your fear is
> justified. We can't expect our busiest contributors to spend time
> answering basic CSS questions.
IIRC, there were seperate groups, which were combined with the aim of
having "our busiest contributors" involved in these discussions.
There was some argument about it at the time...
http://groups.google.com/group/mozilla.dev.mozilla-org/browse_frm/thread/5ab6eb97d4c8ae41
> Create a read-only newsgroup called the "Mozilla Layout Blog", and use
> the feeds from Google Groups to drive blog software.
A read-only newsgroup wouldn't have anything in it to read ;)
But seriously, I don't think what you're suggesting is technically
possible with a newsgroup, because there's no access control. You could
have a mailing list from which messages were then posted to a newsgroup
(but I'm not sure there's any advantage over just having a mailing list
with a web archive or whatever...)
--
Michael
Deb Richardson
> If basic CSS questions are making it through to these lists and groups,
> when they shouldn't be, we need to fix that. Although I'm sure we had a
> discussion about the separation of web-dev and dev and decided to merge
> the groups. Didn't we? Maybe David was dissenting on that occasion.
As I recall, we did not merge these groups -- I believe there is still a
mozilla.dev.tech.layout in addition to mozilla.dev.tech.css. I believe the
argument was about the necessity of a "m.d.web-developer" subhierarchy for
things like css, or whether they could simply live within the "m.d.tech"
area.
My memory is fuzzy here, however, so I could be mistaken.
~ deb
Boris Zbarsky
> Although I'm sure we had a
> discussion about the separation of web-dev and dev and decided to merge
> the groups. Didn't we?
For some definitions of "we", yes (the discussion happened among a set of people
I haven't quite been able to pin down, behind closed doors as far as I can tell).
I wasn't that happy with that decision at the time, either, but people argued
(after the fact of the merge happening) that it should be given a chance.
Well, it has been. And at the moment, m.d.t.layout basically has an incredibly
high noise to signal ratio, if by "noise" we mean various "how do I ...."
questions and by "signal" we mean actual discussion about design and
implementation of layout internals. Maybe that's fine given the purpose of the
group, though? It's not clear to me why the group really exists now.
m.d.t.css is even worse. I suggest you look at the "Stylesheet principals"
thread in m.d.t.css for a typical example of how things go. Note the single
post from dbaron, which basically suggests abandoning m.d.t.css completely (and
which I more or less agree with).
-Boris
Gervase Markham
> Well, it has been. And at the moment, m.d.t.layout basically has an
> incredibly high noise to signal ratio, if by "noise" we mean various
> "how do I ...." questions and by "signal" we mean actual discussion
> about design and implementation of layout internals. Maybe that's fine
> given the purpose of the group, though? It's not clear to me why the
> group really exists now.
If the layout hackers have no public group/list in which they are happy
discussing layout issues, then there is something badly wrong. Let's fix
it. See new top-level message.
> m.d.t.css is even worse. I suggest you look at the "Stylesheet
> principals" thread in m.d.t.css for a typical example of how things go.
That's not good; but you could have just ignored C A Upsdell. Much as
it's nice to correct the clueless, one can get bogged down :-)
Gerv
L. David Baron
> On 2007-02-27, Robert Sayre <say...@gmail.com> wrote:
> [snip]
> >
> > Having observed recent traffic on some of our more technical and
> > specialized mailing lists, like the layout list, I think your fear is
> > justified. We can't expect our busiest contributors to spend time
> > answering basic CSS questions.
>
> IIRC, there were seperate groups, which were combined with the aim of
> having "our busiest contributors" involved in these discussions.
> There was some argument about it at the time...
>
> http://groups.google.com/group/mozilla.dev.mozilla-org/browse_frm/thread/5ab6eb97d4c8ae41
That thread was well after the fact.
I actually didn't know m.d.t.css was created until a month or two
after it happened (which was still before the above thread). It
wasn't in any of the published newsgroup reorganization plans that I
read.
Michael Lefevre
> On Wednesday 2007-02-28 07:59 -0600, Michael Lefevre wrote:
>> There was some argument about it at the time...
>> http://groups.google.com/group/mozilla.dev.mozilla-org/browse_frm/thread/=
> 5ab6eb97d4c8ae41
>
> That thread was well after the fact.
Sorry... I actually wrote and then edited out of my previous post that the
argument about it happened after the decision was made. I didn't realise
quite how far after.
--
Michael
Jean-Marc Desperrier
> So would not also an easy solution to make discussions more open,
> without changing the habits, to archive irc exchanges (like on
> http://bugzilla.glob.com.au/irc/) *and* make sure it's indexed by Google ?
I'm coming back on that to say that I just noticed today bugzilla irc
log got indexed inside google's "supplemental result" (
http://www.google.com/support/webmasters/bin/answer.py?answer=34473 )
It seems it indexes the result of the search for one day each time.
See for example :
http://www.google.com/search?q=mybugstemplate+defaultquery+latter
There's some funny behavior thought :
Searching for "mybugstemplate priority" gives me a irc log page
containing the text 'The mybugstemplate parameter should include', 'the
sort by deadline / priority / severity would be a breeze' that I can not
find when searching for "mybugstemplate priority deadline severity"