Re: How can we decrease the cognitive overhead for contributors?

[Katherine Cox-Buday]

On 9/5/23 5:55 PM, Simon Tournier wrote:
> Hi Katherine,
>
> I am fully aligned with the Survey proposal; at some past Guix Days I
> remember discussing a kind of survey á la Haskell or Emacs surveys.
> Well, such appears to me very informative to better know how to improve,
> from user to contributor.

OK, great! What are next steps, and how can I help?

> On Tue, 05 Sep 2023 at 12:00, Katherine Cox-Buday <cox.katherine.e@gmail.com> 
> wrote:
>
> > 1. A list of the issues
> > 2. How we'll measure that they're issues
> > 3. How we'll measure improvement against the issues
> > 4. How we'll address the issues
> >
> > So often in my long career I've worked with organizations/people that
> > really want to skip to (5): implement something.
> >
> > Implement a vertically-integrated solution to gather feedback against
> > reality: yes. Jump straight to the "final solution" with all the details
> > managed: no.
>
> Since I am French and it is easier for me to comment about my
> disagreements than the converse. ;-)

You keep mentioning you're French as some kind of disparaging thing, but 
all the French people I've met (especially our Guix friends) have been 
kind and thoughtful :)

> In my career, I have seen the converse: spending plenty of time cooking
> all the details of the plan and then being bitten by implementation
> “details” that were impossible to predict beforehand.
>
> Instead, I often see the incremental improvements more productive.
> Especially when people are volunteers for their contributions and so
> their motivation is variable and non-fungible.

I think you've just said the same thing I've said: implement a 
vertically integrated proof of concept and start iterating.

But you need to know the requirements first because even the basic shape 
of your implementation can swing wildly depending on these. E.g. a 
service with three nines of availability can be a fundamentally 
different service than one with four.

> I think we have
>
>   #1. a list of issues; some points discussed in this thread
>       could be reported as bugs.
>   #4. an hope for addressing some of them using a plan (scripts, fix guix
>       edit, etc.)
>
> As we discussed earlier, the ’measures’ are the difficult part and there
> is too many bias that it’s almost impossible to measure.  At best, the
> number of contributors (#2) and some stats from some survey (#3) would
> provide some indicators.

I think almost all surveys ask subjective questions. The bias is OK, 
because in aggregate, it at least points towards a consensus or 
indicates that there are undiscovered problems.

For example: "The Guix logo should be blue: agree/disagree?". This is 
completely subjective, but if 95% of responses disagree, and they 
disagree year-over-year, that's an indication that there's some reason 
it shouldn't be blue.

*Maybe* we even find out that a lot of Guix users are color-blind and 
blue just looks gray.

The point isn't that you practice direct democracy and subject yourself 
to the shifting opinions of the responders. The point is to gather data 
and try and draw conclusions based on what you see.

We should probably go ahead and do what we think is best to improve the 
situation, but we should probably also have a standing question about 
this that we ask in our survey to see if the situation is getting better 
or worse.

> Maybe I misread, I think we have a consensus about the issues and
> about the concrete actionable next steps, no?
>
>   a. Prepare a survey
>   b. Report bugs about “guix style” and “guix edit” (and I am probably
>      missing other reported in the thread :-))
>   c. Look to Build Coordinator and QA [A,B] (ask Chris?) and try to
>      extract what this CI does.
>
> Well, from what my opinion is worth here.
>
> A: https://git.savannah.gnu.org/cgit/guix/build-coordinator.git
> B: https://git.savannah.gnu.org/cgit/guix/qa-frontpage.git/

That all sounds good to me.

Before I opened this can of worms, I was planning on trying to work on 
the Go branch/packages 
(https://lists.gnu.org/archive/html/guix-devel/2023-08/msg00058.html). 
But since I'm the cause of all this, and it will indirectly help me with 
Go things (which is why I brought it up), how can I help?