Re: community input..

[Christian Hergert <christian hergert me>]

On Fri, Dec 8, 2017 at 10:04 AM, Link Dupont <link sub-pop net> wrote:
> Could we run an experiment on a specific project and see how it goes?
> For example with Builder, what function do you feel is lacking the
> most?

I'm not sure I can pinpoint any specific "most". A few of them overlap 
and having someone that can do a little here and there to lighten my 
load would be the most useful.

In that direction, let me address Emily's mail.

On 12/08/2017 04:16 PM, Emily Gonyer wrote:
> As someone who has been, and continues to attempt to become involved
> in the GNOME project without being knee deep in code, I continue to be
> amazed at just how hard that is to achieve. I would love to help with
> project road maps, user feedback, bug testing and common issues, but
> have yet to find anyone interested in helping me to discover exactly
> how I do any of that. Where to even begin? Most developers, in my
> experience are resistant to anyone not knee-deep in code's
> suggestions, feedback, etc.

I spend a lot of time introspecting on this stuff, so let me provide 
some thoughts of what I've discovered in myself.

When working on a project, I often see the project, not in it's current 
state, but in the state for which I am trying to transform it into. This 
is rarely communicated with others because, quite frankly, it's hard to 
even write down in a coherent manner. It's just shapes in my head...

So when someone does have feedback, it's lacking the context of where I 
see the project headed (inside my head). Anything that pulls away from 
that can be difficult to accept and frustrating because it requires 
writing all my ideas down to bring others up to speed.

By addressing some of these missing roles in our teams, I think this can 
be mitigated or avoided altogether, because of the communication 
required when working in teams.

> If there's non-code related stuff you need help with in Builder, I
> would love to know how I can contribute and help.

I have lots of stuff!

There is one major impediment that we have, in that not only do these 
roles need people to fill them, but the roles need to be "bootstrapped" 
as well.

Right now, we don't have product managers, formalized QA on a project, 
release road-maps, or community liaisons. That means whoever wants to 
start doing one of these roles also would have needed to define the role 
they want to fill.

That's hard work, and it doesn't exactly allow people to grow into a 
role because they have to know it before they start. I want to see 
people grow their skill-set when they join the GNOME project, not just 
donate the skills they currently have.

So if I was to define a role that would help me in Builder the most 
right now, it's going to be the combination of a couple roles...

 - First responder to incoming bugs, ensure that the reporter gave us
   enough information to triage. (Which means helping define what that
   type of communication should look like, and working together to
   determine what is "sufficient information" to debug.

 - Analyze the group of bugs that are coming in. Is there a common
   theme? What are the users trying to do that isn't being met? Can
   we solve the problem users have in a different way? Are they using
   the product as intended?

 - Keep an eye on the tasks scheduled for the next release. Are we
   falling behind? Does something need to be cut? Can we get someone
   to help on a specific feature to make sure it lands?

 - Taking all of this information gained from these tasks, it should be
   reasonable to think the person in this role would do a great job of
   helping plan the features for the next release.

   Further more, they are in a good position to help us "steer the ship"
   towards the direction that will be maximally useful to users and the
   vision of the GNOME project alike.

-- Christian