On 2/16/06, Rodrigo Moya <[EMAIL PROTECTED]> wrote: > On Thu, 2006-02-16 at 13:33 -0700, Elijah Newren wrote: > > On 2/16/06, Danilo Šegan <[EMAIL PROTECTED]> wrote: > > > Hi Vincent, > > > > > > Today at 8:24, Vincent Untz wrote: > > > > > > > We'll be trying something new for new modules in 2.16. I think most of > > > > us agree that it didn't turn out well for this cycle. > > > > > > Like: lets remove all desktop modules, and reevaluate them again? > > > > > > Not that it would bring any concrete results, but I'd love the > > > flamefest (d-d-l is seriously lacking these days :) > > > > > > Now, seriously, can you at least give us a hint of what you have in > > > mind? And who is "we" dammit? :) > > > > There are a couple of ideas floating around, so there's no concrete > > change to propose yet. But you'll note that we have sucked at new > > module decisions in all release cycles for the past > > who-knows-how-long. I personally think part of the problem is that > > the end date for new module proposals coincides with the date for the > > final decision. The "discuss it" period is also way too wide open > > making it hard to keep on top of. One of the suggestions is to have > > the cut-off date for new module proposals be sooner, have a focused > > and relatively short (a week or so?) discussion period after that > > (though still allowing the open ended discussion period that currently > > exists, just making it in some sense less official than the focused > > one), and then followed by an actual date by which decisions need to > > be made. > > > > I brought this up at a recent release-team meeting and other ideas > > were also brought up that were somewhat similar in nature (read: I > > don't remember the details). We didn't have anything concrete and > > were running out of time, and besides, 2.14 is taking precedence right > > now. So we agreed to discuss more later and get some community input > > maybe near or after 2.14 is out. But now that it has come up... > > > > Anyone else have any ideas on making us not suck at getting module > > decisions done two months before the release as specified on the > > schedule as opposed to one month like we usually achieve? > > > one thing I don't like is how the decisions get done. That is, if > someone raises some concerns about a proposed module, then "some people > don't like it" is the reason given for not accepting the module (ie, see > gnome-power-manager/screensaver thread). Of course, there would always > be someone who doesn't like something about a proposed module. So, what > if we just set a list of things a module has to conform with to get > accepted and base our decisions on that? > > For instance, we could have: > * uses at least basic platform libs (GTK mainly) > * uses existing platform libraries for everything possible (that is, > does not use libs implementing an already existing feature in GNOME > platform) > * follows GNOME standards (coding standards, freedesktop specs, HIG, > documentation, licensing, release dates and freezes, etc) > * is source in GNOME CVS?
I tried to create such a list in a GEP, ages ago: http://developer.gnome.org/gep/gep-10.html Bottom line: * there are some obvious ones (licensing, CVS, etc.) but those are easy and no one (to the best of my knowledge) has ever proposed anything that didn't meet them, or wasn't trivially moved to them. * you must include evaluations of quality/completeness that are necessarily subjective until the project is evaluated by a wider crowd, and ideally on others, like a11y, that we should include but that realistically no one has time/ability to make the assessments on. So you're always going to have the subjective components, even on reasonably subjective things (is the quality good? is it accessible?) * if the desktop is to remain at all coherent, you must include evaluations of target market/etc. that frankly, as a group, we're basically unable to handle right now. There is no simple, easy, list, unless you have no meaningful standards. Software isn't simple and easy, unfortunately. Luis
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
