On Tue, Jun 1, 2010 at 4:38 PM, Iain
<iain gnome org> wrote:
> > >Bring up and fix issues with GNOME that are being ignored or shunned.
> > Can you list these?
> I will just be frank here...
> Translation shifting from upstream to downstream ?
> Development infrastructure limiting upstream contribution.
> Canonical's Unity development, what does it mean for GNOME ?
> Red Hat's control over GNOME Shell ?
> Meego being a competition or a GNOME sister project ?
> Smaller companies involvement into GNOME decisions
> How much of GNOME is community driven and how much is company driven
> Is the GNOME community forced to assimilate with decisions made by those companies?
> > > Work on letting GNOME shell be lead by the community.
> > Can you expand on what you want changed?
> Currently all GNOME Shell decisions are taken by Red Hat, thus limiting the community's technical as well as design contribution.
It seems to me that your underlying belief is that there is too much
(large) corporate influence in GNOME. Would you say that you might
have some conflict of interest here given that your project
(Zeitgeist) was ignored/shunned by the GNOME Shell developers?
I am not singling out any one party, my concern is just that there are larger parties who don't necessarily seem to be aligned in their technical approaches. Zeitgeist is doing well downstream and Canonical seem very happy with it, yet this is not my concern. My concern is for GNOME.
I don't think it is reasonable to get into a Shell / Zeitgeist discussion here. Although there were some obstacles on the road we did manage to find common ground with McCann's new designs and Owen's technical review. But I won't deny that the experience was *also* a "motivating factor" for me. I will use GNOME Shell however as an example of a corporate driven project:
• The community never intensively evaluated the development and the design.
• The community had very little to say in the decisions of the aforementioned processes.
Just allowing the community to contribute code does not make it a community project. Which also makes marketing GNOME 3 harder for the marketing team.
> > > I stand for innovation in GNOME.
> > What is lacking now, and what do want to do when being part of the board?
> Recently GNOME has not been attracting many new developers. It is because its current development state doesn't allow any new innovation to settle in. GNOME being run mostly by people representing
> bigger companies no risks are being taken and thinking out of the box is usually categorized as such.
Surely one could argue that GNOME Shell is quite innovative thinking
outside of the box, and that quite a large risk is being taken with
it, and most of the suggestions for it that come from the community
are of requests for uninnovative things; "I want a task bar", "I want
applets"
Or is there a potential conflict of interest here as well that
Zeitgeist has not gained much traction in the community?
Again I decide not to get into GS vs ZG discussions here since its just brings up flame-wars, beside the fact that they are not comparable since one is a UI and the other is a service. But there is an impressive community uptake for Zeitgeist if its of interest for you.
Sure GNOME Shell might be innovative in a a Usability perspective but it is the same old desktop. What I meant to say is innovative technologies such as for example semantic desktop technologies that allow new dimensions of User Experience are not being deployed.
> [Redhat or Ubuntu] could start off with a design board combining selected and competent representatives from community and companies, whose first objective is to rewrite the HIG.
...
> I suggest starting a technical board with equal amounts of representatives of companies as and community whose members are significantly competent for the roles.
...
> Recently GNOME has not been attracting many new developers.
Yet you think the solution to attracting new developers is to wrap the
processes up in red tape and technical boards or design boards? Surely
Free Software is supposed to be about meritocracy, not about boards
dictating how an individual project should be run.
Well currently there is a GNOME Shell meritocracy among the RH employees. How is that meritocracy for the community.
Yes I think the solution is setting up boards. It is not a Meritocracy as soon as sole responsibilities are given to a group of individuals affiliated with the same corporation.
iain
