Re: GNOME 2.22 module inclusion discussions heat up.

["Elijah Newren" <newren gmail com>]

Hi Lucas,

These are some great points and questions.  Sadly, they are some of
the same points and questions that have been raised several times over
the past several years and we still have not solved them.  :-(  I'll
answer what I can.

On Jan 4, 2008 8:05 PM, Lucas Rocha <lucasr gnome org> wrote:
> Hi guys,
>
> FYI: Unfortunately, I couldn't properly comment on each proposed
> because the discussions heatup started right in the beginning of my
> vacation.
>
> I just wanted to make two "meta-comments". I plan to write about those
> concerns in more detail as soon as I come back from vacation.
>
> 1. It's not very realistic/eficient to expect the discussions about
> the proposed modules to "heat up" at this time of the year (very close
> to new year and christmas). Because of that, most of the proposed
> modules were poorly discussed. Maybe this should be taken into account
> for next year's schedule?

Yeah, that'd be great.  We have pushed things back slightly (I think
we once had a feature freeze on Jan 1 or something like that.), but it
really needs to be pushed back further.  We should probably try to
extend both 2.24 and 2.26 just slightly (a week each?) to fix this
annual problem; the closeness to the holiday break has been an issue
for a long time and it keeps coming up in complaints.

> 2. There are some problems in the current decision making process
> around modules.
> 2.1 Currently, there's this "consensus-based" process which takes
> place through an open discussion around each proposed module. Nowadays
> there's quite a lot of noise in those discussions and consequently the
> release team often needs to decide based on very poor input from
> community.

This has really always been the case, and I'm not so sure I agree it's
that big of an issue.  Release team members all use their own filters,
and include any input they want (mailing list discussion in
particular, but also irc conversations, blog posts, personal
experience, discussions with maintainers, random biases, etc.)  I
think the release team members in general are pretty good about
filtering noise when making a decision.  Sure, it'll always be a
challenge, but there's a reason the meeting is referred to as
  "Release Team meets about new module decisions for 2.22 with
community input up to this point."
rather than something like
  "Release Team tries to determine new module decisions based on
'majority' vote from mailing list discussions"

We do our best to incorporate community consensus because we want the
decisions to be ones the community can support.  But, technically, if
we think something is seriously wrong we can vote however we want.  If
this were ever to be abused, the foundation board would probably have
to step in, but I think so far it has been used to make sure decisions
reflect the actual majority rather than the 'noisy' majority.  I think
the libnotify/notification-daemon situation is probably a good case.
Personally, I think community consensus was to include those and
depend on them, but the majority of the release team thought that an
extra widget library was too big of a problem and believed otherwise.
I think it's great that the team members feel free to include such
filters in their decisions.

> 2.2 Lack of a sense of direction around those module decisions.
> There's no "big picture" to back the decisions of accepting or denying
> modules. Modules are discussed almost as isolated components. If it
> improves the usability of the desktop in some sane way and covers a
> basic set of requirements, it will be probably in. So, we're basically
> adding "stuff" to the desktop on each major stable release.

Yes, and this has always been a big problem.  I think it goes back to
Havoc's emails (about a year or so ago?) about how we have no mission
statement, and thus no guiding rationale.

Tough nut to crack, and I have no solutions.

> 2.3 The current decision making process doesn't work at all for
> deciding about polemic and fundamental changes in our desktop (and
> we're in a moment which demands from us to change important parts of
> our UI). One of the reasons for that is 2.1 (there are others of
> course). The presence of 2.2 makes things even harder. For example,
> deciding about gimmie, gnome-main-menu, awn, and others, is not just
> about accepting or not a new module, it's about discussing the UI we
> want to provide to our users.

Yes, and like your 2.2 numbered issue, this has always been a problem.
 I have no ideas how we'd go about changing it, but it'd help to have
a clear mission statement for GNOME (though I have no idea how to get
everyone to agree to one, other than the maybe the easiest one
proposed by Havoc).


Hope that helps,
Elijah