I dunno, this sounds a lot like corporate structure sans money. The design team has final say in "Product" experience, the release team has final say in what is or isn't Gnome, and the individual...
I dunno, this sounds a lot like corporate structure sans money.
The design team has final say in "Product" experience, the release team has final say in what is or isn't Gnome, and the individual maintainer has final say in what gets merged.
This structure seems hard bound for multiple power nodes overlapping each other and as a result a conservative appease all the floors approach. Very hard to get fresh conflicting ideas in, and a feedback loop creates itself. Not surprising, then, that Gnome has such controversial reputation.
Another effect of that feedback loop is that internally-discussed reasoning for changes is either not available to the public or is only available to view, not influence. This partially...
Another effect of that feedback loop is that internally-discussed reasoning for changes is either not available to the public or is only available to view, not influence.
This partially contributes to the abrasive relationship GNOME has built with their users.
From this article though, there is no true power anywhere, it's all built on trust with people working in collaboration in many different ways. The power is only there in theory.
From this article though, there is no true power anywhere, it's all built on trust with people working in collaboration in many different ways. The power is only there in theory.
I'd be curious about the project's structure concerning the community-oriented structures. Hopefully that'll sort of come to light in discussing how decisions are made in Part 2, because I'm...
I'd be curious about the project's structure concerning the community-oriented structures. Hopefully that'll sort of come to light in discussing how decisions are made in Part 2, because I'm curious about how a volunteer effort can decide on a vision.
I dunno, this sounds a lot like corporate structure sans money.
The design team has final say in "Product" experience, the release team has final say in what is or isn't Gnome, and the individual maintainer has final say in what gets merged.
This structure seems hard bound for multiple power nodes overlapping each other and as a result a conservative appease all the floors approach. Very hard to get fresh conflicting ideas in, and a feedback loop creates itself. Not surprising, then, that Gnome has such controversial reputation.
Another effect of that feedback loop is that internally-discussed reasoning for changes is either not available to the public or is only available to view, not influence.
This partially contributes to the abrasive relationship GNOME has built with their users.
From this article though, there is no true power anywhere, it's all built on trust with people working in collaboration in many different ways. The power is only there in theory.
Well, there's certainly a great deal of power, it's just hodged in several like-minded people and groups rather than a single person or company.
I'd be curious about the project's structure concerning the community-oriented structures. Hopefully that'll sort of come to light in discussing how decisions are made in Part 2, because I'm curious about how a volunteer effort can decide on a vision.