Re: community input..

[Christian Hergert <christian hergert me>]

On 12/07/2017 06:58 AM, Emily Gonyer wrote:
> Absolutely agree. The resistance to community input in GNOME
> developers has long been a huge impediment to GNOME's wider success,
> and has consistently driven users and outside developers away for
> years.

If we say that that GNOME developers are resistant as a description of 
what happened, I agree. To say that they did so with intention, I do not.

Our current avenues of communication are prone to breakdown (no edit in 
bugzilla?!) and can often suffer from situations like E-S-L and 
different viewpoints for the vision of a project.

GNOME developers are often overworked. Sadly, it comes with the 
territory of such expansive goals. Our desires often outpace our 
contributor growth.

Add to that the huge amount of emotional labor this task requires and 
it's prone to failure. We all need more empathy, but let's also set 
ourselves up for success. People teetering on burnout generally have 
little empathy to spare.

> I'm not sure how to go about including more community input, but
> absolutely agree that doing so could be incredibly helpful to the
> project as a whole long term.

The solution to me is so obvious it hurts.

For example, Builder is a *HUGE* project. Right now, for better or 
worse, I'm doing most of the programming, the project management, the 
product road-map, documentation, discussing future plans with users, bug 
triage, QA, and end-user support. Thankfully we have awesome i18n 
contributors. (Shout to everyone that helps me out, I value you).

In most software companies more than a year old, these are separate full 
time positions. This *MUST* be addressed.

We need more contributors to GNOME that aren't burdened by being knee 
deep in code every day. We need people focusing on the product road-map. 
That requires user feedback, analyzing bug velocity and common issues, 
helping developers prioritize while maintaining the product vision, and 
responsibility for the quality of the end product.

Every time I get new designs from the design time I'm very grateful, 
because that helps with some of these issues. But we really need more 
complete functioning teams because what we have now is insufficient.

There are endless arguments at companies about how to do this. Do you 
have specialized teams by role (ie: "design team" or "QA team") or a 
representative of each product performing these roles (or a hybrid).

-- Christian