Re: Project Proposal: GNOME Innovation

[Sriram Ramkrishna <sri ramkrishna me>]

When we were having discussions on version control systems, one of the
ideas that I had thrown out for a git/bzr over a centralized version
control was that fact that we could branch all of GNOME on an 
experimental branch and create a bazaar for ideas.  A lot of times in
this mailing list we get bogged down over issues of stability and
performance as we are now a mature software project and so we have a
lot of restrictions on how we introduce features into our eco-system.  

But what attracts people is the ability to innovate and be able to
break the rules as it is and be able to express ideas whether they are
crack or not.  We would also be able to attract younger talent and a
new generation of code contributors/maintainers.  Something worth
thinking about and it would be fairly easy to start something like
that, although there is a lot of demons in the details if you want the
branch to actually be useful over time (eg controlled chaos, not chaos)

sri

On Wed, Sep 30, 2009 at 12:29 PM, Wolter Hellmund <wolterh6 gmail com> wrote:

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
>

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list