Well, thanks a lot Brian for the good prospect. You did mention yourself a couple of arguments I forgot in my last reply. For those of you who misunderstood the idea of Innovation, and why it is not the same thing as bugzilla but with votes, here is my explanation: The idea behind Innovation is not to solve bugs for existing projects (it can work that way, but that is not the idea). It is precisely for innovation--for suggesting things never seen before. It is true: manpower is a highly important factor which might conform a weak point for this Innovation Environment. - Best regards, Wolter Hellmund On Wed, 2009-09-30 at 14:15 -0500, Brian Cameron wrote: > Wolter: > > I think your graphic flowchart is a good start. However, a lot of > GNOME modules do not really have active maintainers. To date, I think > the community has dealt with that problem in an ad hoc manner. However, > if we are going to formalize how such a process works, then I think > i would be of value to make it more clear how modules without > active maintainers are maintained. > > Maciej: > > > Ok. The only feature different then bugzilla is vote down AFAIU. > > Moderation is similar to marking NEW and vote up to adding to CC. > > I think one main benefit to the innovation idea is that it creates > an archive where people can, hopefully, go to find out the discussion > behind particular design choices, and what issues were considered. > This can be helpful reference, for example, when trying to make changes > to that code later or replacing it with something new. > > Since much of this discussion has already happened on mailing lists, > it would be especially useful if the innovation tool made it easy > to reference such past threads. It would be neat if you could go > to some website and quickly find links to particular design discussions > that happened in the past, whether on mailing list or captured directly > in the innovation tool. > > This sort of process is also similar to the OpenSolaris ARC > (Architecture Review Committee), where you have a process to help make > architectural decisions. > > http://www.opensolaris.org/os/community/arc/ > > In this process, the focus is on a project's interfaces moreso than > the internal, or private, architecture of a given module. The focus > is more to ensure that modules integrate well together on the system. > For a project like GNOME, there might be more value in studying and > documenting the internal architecture of some modules, though. The > ARC process is probably not the right fit for the GNOME community, > but I'd encourage people to read some about how the process works > and cherry pick any good ideas that might apply. > > Brian >
Attachment:
signature.asc
Description: This is a digitally signed message part