Re: new module decisions [was Re: gnome-screensaver]

[Bryan Clark <bclark redhat com>]

What I'm seeing seems like lack of guidance along with the other points
you mentioned.  For instance this release team reason:

>    + gnome-power-manager: people like it, but some mor work is needed,
>      and more integration should be done. It won't go in for 2.14, but
>      we'd like to see a good integration work starting soon for 2.16.

This reason is a bit too vague and looking back over the thread, I can't
see real positions beyond this.  I've made some notes from re-reading
the gnome-screensaver thread, not to point out anyone (and sorry to
those I point out, it's not about you).  But to point out how vague the
final reasons end up being.

In the "requesting official list of modules and versions for GNOME 2.14"
thread I noted some of these reasons.  (all quoted, out of context, and
probably unfair to the authors [sorry])

        Vincent: It looks great, but it doesn't look integrated enough
        to me, yet.
        Davyd: Let's let vendors decide. This module could do with both
        UI and technical review. The persistant use of the notification
        area, the number of popup bubbles (see above comments on popup
        spam)
        
        Davyd:  hope to get some clarification on what is good
        notification and bad notification that is suitable for the HIG
        shortly.
        ...
        I am proposing that gnome-power-manager has no notification UI
        [...]
        {Lots of discussion on how people think g-p-m could be improved}

As far as I can tell this is the community consensus and the release
team ends up having a similar consensus, both of which are vague and
lacking direction for everyone involved.

I think it would do a lot of good to see the release team format their
decisions more like action items.  That way the module maintainer knows
what needs to be done (as william pointed out) and there can be some
actual debate about the true need for doing it.

Some proposed action items (from me):

* HIG has no real notification area guidelines

        To me this doesn't mean g-p-m is doing anything wrong, just that
        we design / usability people are behind the game and need to get
        our act together.
        
        Here's the current start:
        http://developer.gnome.org/projects/gup/hig/draft_hig_new/desktop-notification-area.html#desktop-notification-balloon

* Needs technical review signed off by the following people, say Davyd,
David, Vincent, and some others?  Those people give a technical signoff
that the bubble "You've been hacked due to a fault in the programming of
g-p-m, Thank you and have a good day" doesn't show up.

        This is a purely technical review, not about if it handles
        notification bubbles wrong.  The release team can select a few
        people who's job it is to openly review the application and sign
        off on it, maintainers of relevant areas are probably good
        candidates.
        
        GNOME gets a few people who are responsible for the official ok,
        the review is done in the open so anyone can participate and we
        actually get something done because a set of people are
        accountable.

* UI Review, all new modules are supposed to get this the most.  It's
most likely all my fault that none of this has been done.

        Similar to running the technical review, select some people to
        be in charge and they get a certain amount of time to work on it
        in the open.  The maintainer should get enough time to respond
        and change, then those people have to give their yes/no vote to
        the release team.

Reasons that wouldn't count, and have counted in the past:

* Not enough integration (sorry vincent, not picking on you; i think
i've said this before too).

        The reason is a bit too vague for anyone to fix and an excellent
        way to become more integrated to to pull these modules into the
        mainline.

* There is some existing functionality that would need to be deprecated.

        As an action item sure, but this shouldn't block inclusion at
        all
        
        We do this all the time, out with the old in with the new even
        if it means multiple modules.  (GGV, GPDF -> Evince is one
        example)

Hope I'm helping,
~ Bryan

On Thu, 2006-02-16 at 13:33 -0700, Elijah Newren wrote:

> There are a couple of ideas floating around,