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, _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list