Re: community input..
- From: Christian Hergert <christian hergert me>
- To: Emily Gonyer <emilyyrose gmail com>, Link Dupont <link sub-pop net>
- Cc: marketing-list <engagement-list gnome org>
- Subject: Re: community input..
- Date: Fri, 8 Dec 2017 21:58:29 -0800
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]