Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")

Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")

[Wilko Meyer]

Hi Guix,

I haven't had enough time to read up on every topic that has been
mentioned in the "How can we decrease the cognitive overhead for
contributors?" discussion as at some point it got quite a lot to
follow. At one point[0] there was a discussion on having a survey to get
a better picture on and quantify what potential blockers are to engage
with/contribute to Guix; which seems, if done right (as surveys have to
be carefully crafted), a good idea; especially with the prospect of
repeating it annually as a means to check if issues got
better/priorities in Guixes userbase change and so on. If there's a
consensus on doing this, I'd be happy to contribute some of my time to
get things going (would creating a issue on guixes bug tracker for this
topic be a good idea? how are these non-code contrib. topics handled?).

Before writing this mail, I had a look on how other projects handle
these kind of surveys, in particular:

- the emacs user survey[1]
- the nix community survey[2]
- the curl user survey[3]
- the fennel survey[4]

I identified a few key themes that could be useful for a guix user
survey as well. I plan on doing a more extensive summary on this later
this weekend if my time allows it, for now a loose collection of
ideas/list of what, in my subjective opinion, stood out and what most
surveys had in common should do to hopefully get a discussion on this
started:

- the emacs user survey specifically asked for elisp profiency; mapping
  out the Guile profiency of guixes community could be feasible.
- fennel as well as emacs had questions on which programming languages
  their community uses; in the regards on recent discussions on
  guix-devel on developer ecosystems[4] this could help to identify if
  there are any shortcomings in providing importers/packages for certain
  languages that may be used by guix users.
- the nix survey specifically asked for the environments and context nix
  is being used in; it'd be interesting to see where and for what
  purpose people are using Guix.
- most surveys had, some more some less extensive, demographic
  questions and questions mapping out how many years people have been
  programming.

Specifially in the lights of the original discussion/regarding
contributions:

- I think that the "Where do you discuss Fennel or interact with other
  Fennel developers" question of fennels survey should be asked for guix
  as well, to get a grasp on which platforms are being used to discuss
  all things guix.
- the curl user survey[6] did a pretty good job in mapping out what
  prevents users from contributing (p.20) as well as mapping out what
  areas of the project are regarding as good/which have room for
  improvements (p.24-26)
- fennel asked for "the biggest problems you have using Fennel", it had
  a "If you haven't hacked on Fennel itself, why not?" question as
  well. I personally think this could be good to assess potential pain
  points/blockers for Guix as well. Fennel also asked for "favorite
  features" which could be a nice way to map out which parts of Guix are
  popular.

Last, the nix user survey allowed free-form responses. Having a
qualitative research component to a survey could help getting better
results (especially when identifying problems in using guix/blockers in
contributing and so on); but evaluating these is pretty time extensive
and dependant on how much resources people have to compile a list of
findings/results from a prospective survey.

What could the next steps be to get this going?

[0]: https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00086.html
[1]: https://emacssurvey.org/
[2]: https://discourse.nixos.org/t/2022-nix-survey-results/18983
[3]: https://daniel.haxx.se/blog/2022/06/16/curl-user-survey-2022-analysis/
[4]: https://fennel-lang.org/survey/2022
[5]: https://lists.gnu.org/archive/html/guix-devel/2023-07/msg00152.html
[6]: https://daniel.haxx.se/media/curl-user-survey-2023-analysis.pdf

-- 
Kind regards,

Wilko Meyer
w@wmeyer.eu

Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")

[MSavoritias]

Sounds like a great idea!

I agree that exclusivity and how we can improve contribution should be 
included.

Also communication channels of course. Maybe also what communication 
channels people would like to see?


Just thinking out loud for questions. I would also be glad to be of help 
with this.


MSavoritias

On 9/16/23 15:59, Wilko Meyer wrote:
> Hi Guix,
>
> I haven't had enough time to read up on every topic that has been
> mentioned in the "How can we decrease the cognitive overhead for
> contributors?" discussion as at some point it got quite a lot to
> follow. At one point[0] there was a discussion on having a survey to get
> a better picture on and quantify what potential blockers are to engage
> with/contribute to Guix; which seems, if done right (as surveys have to
> be carefully crafted), a good idea; especially with the prospect of
> repeating it annually as a means to check if issues got
> better/priorities in Guixes userbase change and so on. If there's a
> consensus on doing this, I'd be happy to contribute some of my time to
> get things going (would creating a issue on guixes bug tracker for this
> topic be a good idea? how are these non-code contrib. topics handled?).
>
> Before writing this mail, I had a look on how other projects handle
> these kind of surveys, in particular:
>
> - the emacs user survey[1]
> - the nix community survey[2]
> - the curl user survey[3]
> - the fennel survey[4]
>
> I identified a few key themes that could be useful for a guix user
> survey as well. I plan on doing a more extensive summary on this later
> this weekend if my time allows it, for now a loose collection of
> ideas/list of what, in my subjective opinion, stood out and what most
> surveys had in common should do to hopefully get a discussion on this
> started:
>
> - the emacs user survey specifically asked for elisp profiency; mapping
>    out the Guile profiency of guixes community could be feasible.
> - fennel as well as emacs had questions on which programming languages
>    their community uses; in the regards on recent discussions on
>    guix-devel on developer ecosystems[4] this could help to identify if
>    there are any shortcomings in providing importers/packages for certain
>    languages that may be used by guix users.
> - the nix survey specifically asked for the environments and context nix
>    is being used in; it'd be interesting to see where and for what
>    purpose people are using Guix.
> - most surveys had, some more some less extensive, demographic
>    questions and questions mapping out how many years people have been
>    programming.
>
> Specifially in the lights of the original discussion/regarding
> contributions:
>
> - I think that the "Where do you discuss Fennel or interact with other
>    Fennel developers" question of fennels survey should be asked for guix
>    as well, to get a grasp on which platforms are being used to discuss
>    all things guix.
> - the curl user survey[6] did a pretty good job in mapping out what
>    prevents users from contributing (p.20) as well as mapping out what
>    areas of the project are regarding as good/which have room for
>    improvements (p.24-26)
> - fennel asked for "the biggest problems you have using Fennel", it had
>    a "If you haven't hacked on Fennel itself, why not?" question as
>    well. I personally think this could be good to assess potential pain
>    points/blockers for Guix as well. Fennel also asked for "favorite
>    features" which could be a nice way to map out which parts of Guix are
>    popular.
>
> Last, the nix user survey allowed free-form responses. Having a
> qualitative research component to a survey could help getting better
> results (especially when identifying problems in using guix/blockers in
> contributing and so on); but evaluating these is pretty time extensive
> and dependant on how much resources people have to compile a list of
> findings/results from a prospective survey.
>
> What could the next steps be to get this going?
>
> [0]: https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00086.html
> [1]: https://emacssurvey.org/
> [2]: https://discourse.nixos.org/t/2022-nix-survey-results/18983
> [3]: https://daniel.haxx.se/blog/2022/06/16/curl-user-survey-2022-analysis/
> [4]: https://fennel-lang.org/survey/2022
> [5]: https://lists.gnu.org/archive/html/guix-devel/2023-07/msg00152.html
> [6]: https://daniel.haxx.se/media/curl-user-survey-2023-analysis.pdf
>

Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")

[Peter Pronai]

Wilko Meyer <w@wmeyer.eu> writes:

> Hi Guix,
>
> I haven't had enough time to read up on every topic that has been
> mentioned in the "How can we decrease the cognitive overhead for
> contributors?" discussion as at some point it got quite a lot to
> follow. At one point[0] there was a discussion on having a survey to get
> a better picture on and quantify what potential blockers are to engage
> with/contribute to Guix; which seems, if done right (as surveys have to
> be carefully crafted), a good idea; especially with the prospect of
> repeating it annually as a means to check if issues got
> better/priorities in Guixes userbase change and so on. If there's a
> consensus on doing this, I'd be happy to contribute some of my time to
> get things going (would creating a issue on guixes bug tracker for this
> topic be a good idea? how are these non-code contrib. topics handled?).
>
> Before writing this mail, I had a look on how other projects handle
> these kind of surveys, in particular:
>
> - the emacs user survey[1]
> - the nix community survey[2]
> - the curl user survey[3]
> - the fennel survey[4]
>
> I identified a few key themes that could be useful for a guix user
> survey as well. I plan on doing a more extensive summary on this later
> this weekend if my time allows it, for now a loose collection of
> ideas/list of what, in my subjective opinion, stood out and what most
> surveys had in common should do to hopefully get a discussion on this
> started:
>
> - the emacs user survey specifically asked for elisp profiency; mapping
>   out the Guile profiency of guixes community could be feasible.
> - fennel as well as emacs had questions on which programming languages
>   their community uses; in the regards on recent discussions on
>   guix-devel on developer ecosystems[4] this could help to identify if
>   there are any shortcomings in providing importers/packages for certain
>   languages that may be used by guix users.
> - the nix survey specifically asked for the environments and context nix
>   is being used in; it'd be interesting to see where and for what
>   purpose people are using Guix.
> - most surveys had, some more some less extensive, demographic
>   questions and questions mapping out how many years people have been
>   programming.
>
> Specifially in the lights of the original discussion/regarding
> contributions:
>
> - I think that the "Where do you discuss Fennel or interact with other
>   Fennel developers" question of fennels survey should be asked for guix
>   as well, to get a grasp on which platforms are being used to discuss
>   all things guix.
> - the curl user survey[6] did a pretty good job in mapping out what
>   prevents users from contributing (p.20) as well as mapping out what
>   areas of the project are regarding as good/which have room for
>   improvements (p.24-26)
> - fennel asked for "the biggest problems you have using Fennel", it had
>   a "If you haven't hacked on Fennel itself, why not?" question as
>   well. I personally think this could be good to assess potential pain
>   points/blockers for Guix as well. Fennel also asked for "favorite
>   features" which could be a nice way to map out which parts of Guix are
>   popular.
>
> Last, the nix user survey allowed free-form responses. Having a
> qualitative research component to a survey could help getting better
> results (especially when identifying problems in using guix/blockers in
> contributing and so on); but evaluating these is pretty time extensive
> and dependant on how much resources people have to compile a list of
> findings/results from a prospective survey.
>
> What could the next steps be to get this going?
>
> [0]: https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00086.html
> [1]: https://emacssurvey.org/
> [2]: https://discourse.nixos.org/t/2022-nix-survey-results/18983
> [3]: https://daniel.haxx.se/blog/2022/06/16/curl-user-survey-2022-analysis/
> [4]: https://fennel-lang.org/survey/2022
> [5]: https://lists.gnu.org/archive/html/guix-devel/2023-07/msg00152.html
> [6]: https://daniel.haxx.se/media/curl-user-survey-2023-analysis.pdf

I definitely vote for having a free form field too, and also an extra
one for feedback on the survey.  It might not be easy to turn it into
quantitative data, but if a lot of people mention certain key words,
that should be both easy to grep for and very apparent even for a casual
reader.

Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")

[Simon Tournier]

Hi,

Really cool!  Thank you.

On Sat, 16 Sep 2023 at 14:59, Wilko Meyer <w@wmeyer.eu> wrote:

> I identified a few key themes that could be useful for a guix user
> survey as well. I plan on doing a more extensive summary on this later
> this weekend if my time allows it, for now a loose collection of
> ideas/list of what, in my subjective opinion, stood out and what most
> surveys had in common should do to hopefully get a discussion on this
> started:
>
> - the emacs user survey specifically asked for elisp profiency; mapping
>   out the Guile profiency of guixes community could be feasible.
> - fennel as well as emacs had questions on which programming languages
>   their community uses; in the regards on recent discussions on
>   guix-devel on developer ecosystems[4] this could help to identify if
>   there are any shortcomings in providing importers/packages for certain
>   languages that may be used by guix users.
> - the nix survey specifically asked for the environments and context nix
>   is being used in; it'd be interesting to see where and for what
>   purpose people are using Guix.
> - most surveys had, some more some less extensive, demographic
>   questions and questions mapping out how many years people have been
>   programming.

I would add the questions as:

 + the kind of contributions: patches, translation, bug report,
 discussions on guix-devel or help-guix, else

 + the number of contributions using some ranges 1, [2-9], [10-100], 100+

 + channels of communication: IRC, guix-devel, help-guix, else (Reddit,
 etc.)

 + contribution to other free software (patches, translation, bug
 report)

 + editor of choice (as the survey from Haskell [1])

 + and maybe some other questions from [1] :-)

WDYT?

1: https://taylor.fausak.me/2022/11/18/haskell-survey-results/#s3q1

Cheers,
simon

Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")

[Wilko Meyer]

Hi Simon,

Simon Tournier <zimon.toutoune@gmail.com> writes:

> I would add the questions as:
>
>  + the kind of contributions: patches, translation, bug report,
>  discussions on guix-devel or help-guix, else
>
>  + the number of contributions using some ranges 1, [2-9], [10-100], 100+
>
>  + channels of communication: IRC, guix-devel, help-guix, else (Reddit,
>  etc.)
>
>  + contribution to other free software (patches, translation, bug
>  report)
>
>  + editor of choice (as the survey from Haskell [1])
>
>  + and maybe some other questions from [1] :-)
>
> WDYT?

These are excellent ideas. I think there was a discussion on this
mailing list recently on communication channels (e.g. on having a web
forum iirc) so asking what channels of communications participants
currently use and what they would like to use seems like a good idea.

Asking about contributions to other free software projects and what type of
contributions people make also seems quite interesting.

I'll have a closer look at the Haskell survey later on; for now I think
it'd be a good idea to share my .org outline on prospective survey
questions. It's far from being a usable and polished questionaire and
mostly contains question ideas grouped by prospective topics loosely
based on the discussions on this mailing list.

Feedback, ideas, different questions, and edits are always appreciated
as I'm pretty sure I'm probably missing out on areas that are important
to other folks on this mailing list/for Guix as a whole.

--- guix-survey-questions.org ---

* Guix Survey Questions

** Demographic

- Which region do you live in? (providing a set of regions)
- How old are you? (providing a set of age ranges?)
- What is your gender identity? (freeform)
- Field of work
  
** Technical/Usage
*** Guix as a Package Manager

**** General Usage of Guix

- Why do you use Guix? (freeform)
- Where/on what platform do you use Guix? (Guix System, on top of other
  distributions etc.)
- How many years have you been using Guix?
- In what context do you use Guix? (academic, work, private etc.)
- What do you use Guix for? (packaging, systemconf, reproducible
  research and so on)
  ...system configuration
  ...home configuration (guix home)
  ...setting up development environments (guix shell)
  ...for container shells (guix shell --container)
  ...building and packaging software (guix build)
  ...accessing older versions of software/of guix (guix time-machine)
  ...to bundle software for non-guix targets (guix pack)
  ...possibly more use cases or freeform?
- Have you ever considered to stop using Guix, if so why? (freeform)
- Which features keep you using Guix? (should be a list with optional
  freeform)
- What other package managers do you use?
- If you couldn't use Guix, what would be your preferred alternative?
- To extend guix packages/work on new packages, you...
  ...upstream to guix proper
  ...maintain a fork of guix proper
  ...maintain your own guix channel
  ...provide a guix.scm for the respective projects

**** Guix for Software-Development

- Do you use Guix for software development?
- What languages do you work with?
- Do you use guix import/are there importers missing?
- Is there a build system for a language you use missing?
- What features of Guix are part of your developer workflow?

*** Guix System

- Do you use Guix System? (exclusion criterion for the following
  questions if not)

  ...Yes, as my main OS.
  ...Yes, but I mainly use other OS.
  ...No

- How many years have you been using Guix System?
- Have you used Guix as a foreign package manager on another
  distribution before starting to use Guix System?
- Hardware related questions (ISA, Laptop/Desktop, avail. RAM;
  shouldn't go too much into detail)
- Which other OS do you regularly use besides Guix System?
- Why did you choose to use Guix System?
- Which features of Guix Systems are important to you?

*** Guile

- How many years have you been using Guile?
- How many years have you been coding in general?
- Have you been using Guile or another Scheme implementation before
  using Guix?
- What is your level of Guile proficency?

** Contributions/Community

*** Communications

- Which communication channels do you use to talk about Guix?

  guix-devel
  help-guix
  IRC
  Matrix

- Is there any relevant communication channel missing?

*** Contributions

- What describes your involvement with Guix the best?

  ...I just use Guix as a package manager
  ...I use Guix to package software/as a part of my development routine
  ...I contribute packages/patches to Guix proper
  ...I contribute packages/patches to other Channels
  ...I have commit access to Guix proper
  ...Other/freeform

- Have you and in what form contributed to Guix?

  Yes, via patches
  Yes, via translations
  Yes, I file bug reports
  Yes, I partake in discussions on e.g. guix-devel
  Yes, other
  No.

- If not, what prevents you from contributing? (this should be a list
  with a freeform option)
- Have you contributed to Guix in the past and stopped, if so what
  were your reasons? (list of options with freeform)
- When was your first contribution to Guix?
- Can you give a rough estimate on your number of contributions?
- What resources have you used for help to prepare a contribution?

  Guix Manual
  IRC
  Mailing lists and so on...

- What text editor do you use to hack on Guix?

*** Misc.

- If there's one thing about Guix you could change/improve, what would
  it be?

- What would you see as the best, what would you see as the worst area
  of Guix?

- Anything missing in this survey? What topic would you like to see
  covered?

-- 
Kind regards,

Wilko Meyer
w@wmeyer.eu

Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")

[Katherine Cox-Buday]

This is awesome, thanks Wilko!

I've been talking with my wife who is the field of psychology. As part 
of her degree, and as part of her ongoing education, she's studied how 
to design studies/surveys so that they're not biased and don't produce 
contaminated data. She's not an expert at this, but she knows more about 
it than me :)

The things we could come up with which we thought were important to 
consider are:

- You must first define your goals for the survey. Is it meant to see
   who is using Guix? Who is contributing? How they find the
   contribution process? How they find using Guix? There are many
   dimensions, and we may need to create more than one survey.

- The medium of the survey is very important. E.g. some people won't
   reply to a survey served something that uses JavaScript. Some people
   may not be able to reply to a survey unless accessibility concerns
   are met. Some people won't overcome the barrier of having to log in
   to respond.

- Where solicitations to complete the survey are broadcast is very
   important. E.g. if we only send it to guix-dev, this skews the
   responses to questions like "where do you talk about Guix".

- When the solicitations are made is very important. Some religions do
   not allow use of electronics on certain days, or times of the year.
   Some people are away on holiday during parts of the year. Some
   people are trying to meet deadlines during fiscal quarters. It may
   be impossible to accommodate everyone, but giving a little
   consideration to the issue and a sufficient window of time may cover
   most cases.

- When soliciting responses to the survey, it's very important to set
   expectations about the survey in the solicitation. It is important
   to briefly describe what the survey is like and how long the survey
   will take. Without this, some people will have uncertainty about
   what they're committing to and not even try.

- The survey should endeavor to remain on the shorter end; many will
   not complete longer surveys.

- Does the survey need translation to eliminate language barriers?

- The survey should use a uniform measurement system throughout. Don't
   use scales with different magnitudes in different questions, and
   don't suddenly invert whether higher is better or worse.

- As you've already mentioned, free-form questions are very difficult
   to quantify, and I think we should use them with caution.
   Communities rooted in philosophical values, as Guix is, have
   impassioned people and resolving a large number of free-form
   responses to a quantitative statement may be difficult.

- Questions which are intended to solicit a agree/disagree should be
   phrased as "I" questions, e.g.:

	On a scale of 1-5, how much do you agree with the phrase "I
	like carrots"?

- Questions should not be leading, and be biased towards the positive.
   E.g., with the carrots example, don't do this:

        Carrots are disgusting. How much do you agree with this?

   and don't do this:

         On a scale of 1-5, how much do you agree with the phrase "I
         think carrots are disgusting!"

- Up front, it may be difficult to identify all the root-causes of
   something the project wants to know about. Instead of trying to
   infer these, ask the questions directly. E.g. instead of questions
   about liking crunchy vegetables, orange vegetables, and root
   vegetables, ask whether they like carrots.

   However, if you think you have some idea of the root-causes, you can
   ask those as well to see if the correlation you think exists does.

- You may want to ensure the survey has "marker questions" which
   clearly categorize your responder for you to make it easier to make
   the statements you'd like to make. E.g. if you're interested in
   analyzing what vegetarians vs omnivores think of carrots, ask that
   so you don't have to try and infer it later.

- We were unable to resolve the question of astroturfing wherein one
   malicious party responds many times to skew the data. This might be
   difficult to address without relying on a vendor who has solved this
   concern somehow, but requires logins, JavaScript, or something else
   people won't use.

And finally, I'd like to suggest:

I think since this is the result of a discussion about how to lower the 
cognitive overhead of contributing, the goal of this initial survey 
should be:

1. To quantify how easy it is to contribute to Guix.
2. To quantify how easy it is to maintain Guix.
3. To correlate (1) and (2) with people's opinion of using email for 
contributions.
4. To correlate (1) and (2) with people's opinion of using a forge for 
contributions.
5. To correlate (1) and (2) with people's opinion on only improving tooling.
6. To be able to do trend-analysis year-over-year on these issues.

I would suggest adding these questions to a survey exploring the 
contribution process:

     On a scale of 1-5, 1 being "Strongly Disagree" and 5 being
     "Strongly Agree", how much do you agree with the statements:

     "I think it is easy to contribute to Guix."

     "I think contributions to Guix will be reviewed in a timely
     manner."

     "I think email is the best way to manage introducing code to
     Guix."

     "I think a web-forge is the best way to manage introducing code to
     Guix."

     "I think working on tools made specifically for Guix is the best
     way to improve the contribution process."

I am very interested in the usage patterns of Guix, and I firmly believe 
some survey should explore this. I'm not sure if we should combine the 
two; does it make it too long of a survey?

Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")

[Wilko Meyer]

Hi Katherine,

Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:

> This is awesome, thanks Wilko!
>
> I've been talking with my wife who is the field of psychology. As part
> of her degree, and as part of her ongoing education, she's studied how
> to design studies/surveys so that they're not biased and don't produce
> contaminated data. She's not an expert at this, but she knows more
> about it than me :)

This is super valuable! Thanks for taking the time to share so many
detailed and elobarate considerations on how to design surveys in
general and a survey for guix specifically. This was super interesting
to read and to think about!

> The things we could come up with which we thought were important to
> consider are:
>
> - You must first define your goals for the survey. Is it meant to see
>   who is using Guix? Who is contributing? How they find the
>   contribution process? How they find using Guix? There are many
>   dimensions, and we may need to create more than one survey.

Given the original thread on this list, I'd say the focus should be on the
contribution process, secondarily on who is contributing and maybe the
areas Guix is used in? As much as I'd love to see an extensive survey
that also covers a more detailed picture on Guix usage/e.g. focusses on
particular technical aspects of Guix; I'd have to agree that a narrower
scope that provides data for the issues that have been discusses in the
original thread is probably better (especially considering that the
results have to be analyzed/interpreted and time tends to be a rather
limited resource).

> - The medium of the survey is very important. E.g. some people won't
>   reply to a survey served something that uses JavaScript. Some people
>   may not be able to reply to a survey unless accessibility concerns
>   are met. Some people won't overcome the barrier of having to log in
>   to respond.

I'm by no means an expert on accessibility; AAA-level contrast,
screenreader compatibility, and using a dyslexic friendly typeface by
default should be things to consider as a default. It'd be interesting
to see how other surveys (e.g. Nix, Emacs, Haskell and so on) are
handling these things.

> - Where solicitations to complete the survey are broadcast is very
>   important. E.g. if we only send it to guix-dev, this skews the
>   responses to questions like "where do you talk about Guix".

Definitely, I'm not entirely sure on how to solve this; publishing
surveys on as many channels that seem fitting could maybe mitigate this?
Then again the selection of communication channels is highly subjective
as well.

> - When the solicitations are made is very important. Some religions do
>   not allow use of electronics on certain days, or times of the year.
>   Some people are away on holiday during parts of the year. Some
>   people are trying to meet deadlines during fiscal quarters. It may
>   be impossible to accommodate everyone, but giving a little
>   consideration to the issue and a sufficient window of time may cover
>   most cases.

This is also something where input from other survey creators could
help; I would guess that having a relatively broad participation window
could be part of a solution.

> - When soliciting responses to the survey, it's very important to set
>   expectations about the survey in the solicitation. It is important
>   to briefly describe what the survey is like and how long the survey
>   will take. Without this, some people will have uncertainty about
>   what they're committing to and not even try.
>
> - The survey should endeavor to remain on the shorter end; many will
>   not complete longer surveys.

This is another good reason to start with a narrow focus on questions
regarding contributions instead of a general survey.

> - Does the survey need translation to eliminate language barriers?

Most FLOSS surveys I've looked at were english only; which comes with a
certain language bias. Realistically I'd say that, given a survey may
contain free form questions, translation also seems to be a resource
issue when it comes to analyzing the results.

> - The survey should use a uniform measurement system throughout. Don't
>   use scales with different magnitudes in different questions, and
>   don't suddenly invert whether higher is better or worse.

Good point, this also means that questions should be asked in a way,
that they can be answered using the same metrics/scale?

> - As you've already mentioned, free-form questions are very difficult
>   to quantify, and I think we should use them with caution.
>   Communities rooted in philosophical values, as Guix is, have
>   impassioned people and resolving a large number of free-form
>   responses to a quantitative statement may be difficult.

My approach to free form questions is to, on one hand try to quantify
trends (things that are mentioned often, key topics that are mentioned),
on the other try to derrive actionable items/issues from them that can
be worked on. Quantifiying qualitative responses is cumbersome, and as
you've also pointed out, quite difficult; but identifying trends/key
topics and maybe actionable items/issues from those could work. WDYT?

> - Questions which are intended to solicit a agree/disagree should be
>   phrased as "I" questions, e.g.:
>
> 	On a scale of 1-5, how much do you agree with the phrase "I
> 	like carrots"?
>
> - Questions should not be leading, and be biased towards the positive.
>   E.g., with the carrots example, don't do this:
>
>        Carrots are disgusting. How much do you agree with this?
>
>   and don't do this:
>
>         On a scale of 1-5, how much do you agree with the phrase "I
>         think carrots are disgusting!"
>
> - Up front, it may be difficult to identify all the root-causes of
>   something the project wants to know about. Instead of trying to
>   infer these, ask the questions directly. E.g. instead of questions
>   about liking crunchy vegetables, orange vegetables, and root
>   vegetables, ask whether they like carrots.
>
>   However, if you think you have some idea of the root-causes, you can
>   ask those as well to see if the correlation you think exists does.

If we've a first draft of a prospective, narrowed-down on contributions,
survey, the questions should probably be benchmarked against these
criteria. I revisted my loose collection of survey questions I posted
earlier on here and realized that I probably have to rephrase a vast
majority of those, to be consistent with this.

> - You may want to ensure the survey has "marker questions" which
>   clearly categorize your responder for you to make it easier to make
>   the statements you'd like to make. E.g. if you're interested in
>   analyzing what vegetarians vs omnivores think of carrots, ask that
>   so you don't have to try and infer it later.

I'll revisit the original thread on how to decrease cognitive overhead
for contributors to see what good markers could be. With a grain of
salt, I think we should figure out ways to identify participants that:

- were contributors to guix before but stopped contributing
- want to contribute but experienced blockers that stopped them from
  participating

as well as a way to map out e.g. the frequency of contributions?

> - We were unable to resolve the question of astroturfing wherein one
>   malicious party responds many times to skew the data. This might be
>   difficult to address without relying on a vendor who has solved this
>   concern somehow, but requires logins, JavaScript, or something else
>   people won't use.

The emacs survey doesn't require javascript; they've build a
self-written survey framework in julia iirc to address issues revolving
around javascript and finding ways to do input validation. I don't know
if they've explicitly tried to implement measures against astroturfing
or how their survey framework works in general; but it may be worth
considering. 

> And finally, I'd like to suggest:
>
> I think since this is the result of a discussion about how to lower
> the cognitive overhead of contributing, the goal of this initial
> survey should be:
>
> 1. To quantify how easy it is to contribute to Guix.
> 2. To quantify how easy it is to maintain Guix.
> 3. To correlate (1) and (2) with people's opinion of using email for
> contributions.
> 4. To correlate (1) and (2) with people's opinion of using a forge for
> contributions.
> 5. To correlate (1) and (2) with people's opinion on only improving tooling.
> 6. To be able to do trend-analysis year-over-year on these issues.
>
> I would suggest adding these questions to a survey exploring the
> contribution process:
>
>     On a scale of 1-5, 1 being "Strongly Disagree" and 5 being
>     "Strongly Agree", how much do you agree with the statements:
>
>     "I think it is easy to contribute to Guix."
>
>     "I think contributions to Guix will be reviewed in a timely
>     manner."
>
>     "I think email is the best way to manage introducing code to
>     Guix."
>
>     "I think a web-forge is the best way to manage introducing code to
>     Guix."
>
>     "I think working on tools made specifically for Guix is the best
>     way to improve the contribution process."

These questions are excellent to address large parts of the issues being
discussed in the original thread on this list.

> I am very interested in the usage patterns of Guix, and I firmly
> believe some survey should explore this.
> I'm not sure if we should combine the two; does it make it too long of
> a survey?

I'd say, that it could be beneficial to ask for usage as long as it
helps to map out the background of guixes users. I wouldn't go too much
into detail, but this subset of questions on general usage I shared
before (and maybe a question on familiarity with Guile/Scheme) would
still provide value:

>> - Why do you use Guix? (freeform)
>> - Where/on what platform do you use Guix? (Guix System, on top of other
>>   distributions etc.)
>> - How many years have you been using Guix?
>> - In what context do you use Guix? (academic, work, private etc.)
>> - What do you use Guix for? (packaging, systemconf, reproducible
>>   research and so on)
>> - Have you ever considered to stop using Guix, if so why? (freeform)
>> - Which features keep you using Guix? (should be a list with optional
>>   freeform)
>> - To extend guix packages/work on new packages, you...
>>   ...upstream to guix proper
>>   ...maintain a fork of guix proper
>>   ...maintain your own guix channel
>>   ...provide a guix.scm for the respective projects

to assess the questionees background better/be able to give more
context. WDYT?

-- 
Kind regards,

Wilko Meyer
w@wmeyer.eu

Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")

[Katherine Cox-Buday]

On 10/2/23 5:24 AM, Wilko Meyer wrote:

>> - Where solicitations to complete the survey are broadcast is very
>>    important. E.g. if we only send it to guix-dev, this skews the
>>    responses to questions like "where do you talk about Guix".
> 
> Definitely, I'm not entirely sure on how to solve this; publishing
> surveys on as many channels that seem fitting could maybe mitigate this?
> Then again the selection of communication channels is highly subjective
> as well.

I don't think we have to be very selective about where to broadcast the 
survey. I think the answer is: anywhere Guix people hang out or anyone 
feels it might be useful to do so.

I think the only danger here is missing some popular hangout spots due 
to ignorance of their existence. We should enumerate them to ensure we 
catch them all.

>> - When soliciting responses to the survey, it's very important to set
>>    expectations about the survey in the solicitation. It is important
>>    to briefly describe what the survey is like and how long the survey
>>    will take. Without this, some people will have uncertainty about
>>    what they're committing to and not even try.
>>
>> - The survey should endeavor to remain on the shorter end; many will
>>    not complete longer surveys.
> 
> This is another good reason to start with a narrow focus on questions
> regarding contributions instead of a general survey.
> 
>> - Does the survey need translation to eliminate language barriers?
> 
> Most FLOSS surveys I've looked at were english only; which comes with a
> certain language bias. Realistically I'd say that, given a survey may
> contain free form questions, translation also seems to be a resource
> issue when it comes to analyzing the results.

Does the GNU project have a "general translation" team?

Maybe some of our Guix community members who speak multiple languages 
would be willing to translate the survey into their primary language?

>> - The survey should use a uniform measurement system throughout. Don't
>>    use scales with different magnitudes in different questions, and
>>    don't suddenly invert whether higher is better or worse.
> 
> Good point, this also means that questions should be asked in a way,
> that they can be answered using the same metrics/scale?

I think that's the idea and should be the rule for which there are 
exceptions.

>> - As you've already mentioned, free-form questions are very difficult
>>    to quantify, and I think we should use them with caution.
>>    Communities rooted in philosophical values, as Guix is, have
>>    impassioned people and resolving a large number of free-form
>>    responses to a quantitative statement may be difficult.
> 
> My approach to free form questions is to, on one hand try to quantify
> trends (things that are mentioned often, key topics that are mentioned),
> on the other try to derrive actionable items/issues from them that can
> be worked on. Quantifiying qualitative responses is cumbersome, and as
> you've also pointed out, quite difficult; but identifying trends/key
> topics and maybe actionable items/issues from those could work. WDYT?

My opinion is that we should not do free form questions for this first 
time. We're new at this, we have enough topics to cover, and the topics 
we are covering seem to cause a lot of discussion (that's good) which 
could lead to a lot of text to read through.

>> - Up front, it may be difficult to identify all the root-causes of
>>    something the project wants to know about. Instead of trying to
>>    infer these, ask the questions directly. E.g. instead of questions
>>    about liking crunchy vegetables, orange vegetables, and root
>>    vegetables, ask whether they like carrots.
>>
>>    However, if you think you have some idea of the root-causes, you can
>>    ask those as well to see if the correlation you think exists does.
> 
> If we've a first draft of a prospective, narrowed-down on contributions,
> survey, the questions should probably be benchmarked against these
> criteria. I revisted my loose collection of survey questions I posted
> earlier on here and realized that I probably have to rephrase a vast
> majority of those, to be consistent with this.
> 
>> - You may want to ensure the survey has "marker questions" which
>>    clearly categorize your responder for you to make it easier to make
>>    the statements you'd like to make. E.g. if you're interested in
>>    analyzing what vegetarians vs omnivores think of carrots, ask that
>>    so you don't have to try and infer it later.
> 
> I'll revisit the original thread on how to decrease cognitive overhead
> for contributors to see what good markers could be. With a grain of
> salt, I think we should figure out ways to identify participants that:
> 
> - were contributors to guix before but stopped contributing
Maybe:

      (1) Have you made contributions to Guix in the past?

This is our marker question.

combined with:

      (2) How many contributions to Guix per month would you estimate
      you've made in the past year? (identify ranges we're interested in)

This is a dimension that would be useful to have for analyzing other 
responses. We can infer that

> - want to contribute but experienced blockers that stopped them from
>    participating

      (3) On a scale of 1-5, how much do you agree with the statement, "I
      would like to contribute to Guix."

combined with

      (4) On a scale of 1-5, how much do you agree with the statement, "I
      think it is easy to contribute to Guix."

We can then infer that people with higher scores to (3), lower scores to 
(4), and low contribution ranges from (2) are experiencing blockers that 
stop them from participating.

> as well as a way to map out e.g. the frequency of contributions?

(covered above)

>> And finally, I'd like to suggest:
>>
>> I think since this is the result of a discussion about how to lower
>> the cognitive overhead of contributing, the goal of this initial
>> survey should be:
>>
>> 1. To quantify how easy it is to contribute to Guix.
>> 2. To quantify how easy it is to maintain Guix.
>> 3. To correlate (1) and (2) with people's opinion of using email for
>> contributions.
>> 4. To correlate (1) and (2) with people's opinion of using a forge for
>> contributions.
>> 5. To correlate (1) and (2) with people's opinion on only improving tooling.
>> 6. To be able to do trend-analysis year-over-year on these issues.
>>
>> I would suggest adding these questions to a survey exploring the
>> contribution process:
>>
>>      On a scale of 1-5, 1 being "Strongly Disagree" and 5 being
>>      "Strongly Agree", how much do you agree with the statements:
>>
>>      "I think it is easy to contribute to Guix."
>>
>>      "I think contributions to Guix will be reviewed in a timely
>>      manner."
>>
>>      "I think email is the best way to manage introducing code to
>>      Guix."
>>
>>      "I think a web-forge is the best way to manage introducing code to
>>      Guix."
>>
>>      "I think working on tools made specifically for Guix is the best
>>      way to improve the contribution process."
> 
> These questions are excellent to address large parts of the issues being
> discussed in the original thread on this list.
> 
>> I am very interested in the usage patterns of Guix, and I firmly
>> believe some survey should explore this.
>> I'm not sure if we should combine the two; does it make it too long of
>> a survey?
> 
> I'd say, that it could be beneficial to ask for usage as long as it
> helps to map out the background of guixes users. I wouldn't go too much
> into detail, but this subset of questions on general usage I shared
> before (and maybe a question on familiarity with Guile/Scheme) would
> still provide value:
> 
>>> - Why do you use Guix? (freeform)
>>> - Where/on what platform do you use Guix? (Guix System, on top of other
>>>    distributions etc.)
>>> - How many years have you been using Guix?
>>> - In what context do you use Guix? (academic, work, private etc.)
>>> - What do you use Guix for? (packaging, systemconf, reproducible
>>>    research and so on)

This might be too broad a question since Guix is an operating system.

>>> - Have you ever considered to stop using Guix, if so why? (freeform)
>>> - Which features keep you using Guix? (should be a list with optional
>>>    freeform)

This might also be too broad a question since people's motivations are 
likely to be varied.

>>> - To extend guix packages/work on new packages, you...
>>>    ...upstream to guix proper
>>>    ...maintain a fork of guix proper
>>>    ...maintain your own guix channel
>>>    ...provide a guix.scm for the respective projects
> 
> to assess the questionees background better/be able to give more
> context. WDYT?

As discussed above, my opinion is that we should drop the free-form 
questions. Other than that and my comments, I'd be OK with including 
these style of questions in this survey.

But these are my opinions. I'm open to discussion!

Is this rough list of questions our first pass at what the survey should 
contain?

Have you done any more research on what other communities are doing?

What are next steps?

Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")

[Simon Tournier]

Hi,

On Mon, 09 Oct 2023 at 12:29, Katherine Cox-Buday <cox.katherine.e@gmail.com> wrote:

> Is this rough list of questions our first pass at what the survey should 
> contain?
>
> Have you done any more research on what other communities are doing?
>
> What are next steps?

Well, from my opinion, since the idea is to send once a year this
survey, the next steps seems sending a first patch.  Let say the Git
repository maintenance under doc/ and plain text file (or Org or
Markdown).

https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc

Then, as any other change, we can comment and iterate (v2, v3, etc.)
until we are fine with the questions and wordings.  Once we have some
LGTM, let install the file.

End of step 1-a.  In parallel, step 1-b: how to distribute the survey
and collect answers?

Then step 2.  Etc. :-)

WDYT?

Cheers,
simon

Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")

[Wilko Meyer]

Hi Katherine,

I haven't had too much time lately in regards of the survey, but hope
I'll be able to commit more time to it throughout the next weeks. Thanks
for reviewing the first rough draft of the questions!

Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:

> Does the GNU project have a "general translation" team?
>
> Maybe some of our Guix community members who speak multiple languages
> would be willing to translate the survey into their primary language?

I'm not too familiar with the structures of the GNU project; but there's
a page mentioning translation teams for several languages at
least[0]. Don't know how active these teams are, so maybe reaching out
to other community members on this list would be a better bet?

> My opinion is that we should not do free form questions for this first
> time. We're new at this, we have enough topics to cover, and the
> topics we are covering seem to cause a lot of discussion (that's good)
> which could lead to a lot of text to read through.

Agreed, having quantitative questions only already seems like a good
amount of work; even though free form would be quite interesting,
that's, as you said, out of scope for the first survey.

> Have you done any more research on what other communities are doing?

I did! Hope I'll be able to write a good cohesive summary of my org-roam
notes on this to share in this thread soon-ish.

> What are next steps?

I think Simons idea of collecting our questions somewhere and improving
those until we're happy/able to start the survey period sounds like a
good plan. If time permits, I'll put the rough list of questions we have
now in a .org document and open an issue containing them; so we have a
place where the survey questions can be edited/improved/discussed. WDYT?

[0]: https://www.gnu.org/server/standards/README.translations.en.html#teams

-- 
Kind regards,

Wilko Meyer
w@wmeyer.eu

Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")

[Tao Hansen]

Hello, I hope it's ok I'm replying to this email as a follow-up to
decreasing the cognitive overhead for new users. I'm also brand new to
the Guix community and ecosystem. I wanted to share a perspective from a
user on a Lemmy instance who wrote why the Guix ecosystem was not
friendly enough to meet them where they were, a person in their early
twenties. I'd like to suggest approach their criticism with compassion
and open-mindedness.

@velox_vulnus writes at https://lemmy.ml/comment/4625080

> I don’t like the vibe of ageism against young people that is
> associated with GNU. What is also frustrating is their reluctance to
> improve their infrastructure.

> This reason is kind of terrible, I admit, but they could choose to
> move over to Matrix over IRC, but they choose to be willingly open to
> spam over having a proper, documented chat channel. I am also
> reluctant to use my personal mail, for the mailing list. Matrix gives
> me that anonymity, without also having to geopardize on participation.
> NixOS is on Matrix, and that’s why I like it. I know Matrix isn’t
> perfect, but it the better choice between any other messenger.

This user could use an email address dedicated to Guix discussion but
really I can only agree that sticking to IRC, which requires a lot of
effort to keep a history log and more effort to host a bouncer makes
contributing to synchronous discussions difficult. I, myself, am only
active on the community-run Matrix server and another, less free,
channel because the overhead is just too high. 

> They could choose to remove non-Libre JS from GitLab, Sourcehut or
> Gitea, or at least come with a new source hosting platform, but they
> choose not to. 

I also have a hard time with the insistence on the "Old Ways" as somehow
more pure, more legitimate than the new. There's some sense of the
expression, "You kids get off my lawn!" And the decentralized nature of
sending Git patches by email, which I still have not ventured to try,
makes it hard to *discover* Guix development in a single place. A user
needs to go to any one of the mailing lists, pull the Git repo or browse
Savannah or the issue frontend for bugs and new features they might be
interested in, and generally have an idea of what they want to be
looking for to find it. Discovery by serendipity is missing.

When using the mailing list, even figuring out how to reply to the right
thread here in Gnus is trying and I'm not even sure if I've done it
right: people change the subject line, threads grow so large they become
unmanageable; I had to make sure I CC'd the whole list instead of just
reply to this mail's author. I still haven't figured out how to stick
guix-devel in my Gnus home screen: my starting view is always empty
and I have to remember the shortcut to get to the gigantic overview of
every Gmane list (this isn't a cry for help).

There's more to their post: I encourage folks to check it out.

We have the FOSS technology to tackle a lot of these critiques and bring
in a whole new wave of contributors. We have fully open Git forges and
modern messaging protocols to make a brand new developer-friendly Guix a
reality.

Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")

[Lucy Coleclough]

[-- Attachment #1: Type: text/plain, Size: 6794 bytes --]

To counter this point:
> But the present organisation looks defunct. There’s no strong leadership.
A lack of central-ised leadership is a good thing
If this is their only reason for calling the organisation defunct then this
point is invalid however I am unsure if this is where the critique lies

In that spirit i am pondering how something akin to central leadership
mandating such a change occur in this environment.
The biggest concern I can think of about doing something like this and
degrading existing workflows would be alienating developers who prefer the
existing methods and perhaps had a hand in making them what they are
currently.
A lot of people in a company would likely grumble about such a mandate as a
way of getting over it.
I guess here some examples:
- consensus could be tried for in a formal polling process and it be worked
on post consensus
- one could also do the work and propose it then to dispell any concerns of
achievability but at the risk of it not being used
- one could also try building an approach in which the project would
gradually fade into a state where both options are viable, and then
perhaps, should consensus be reached then, the project could fade into a
state with solely the changed tooling
    example stages:
        - current tooling
        - git repo-s mirrored, chat channel-s bridged
        - facilitate project interaction on new git hosting method (
issues, mr-s, ...)
        - fade towards solely using the consensus desired tooling

I think consensus is more suitable to large decisions than voting when
maintenance of the group boundary ( guix devs) and maintenance of the
number of states ( a set of tooling with only one tool per use case (
savannah or gitlab, matrix or irc, ...)) is desired
an issue like this could cause a split and sometimes that is ok
but when that is undesirable, if the one resulting state is formed then a
continuous discussion process to form this one state into something which
has the least cummulative "friction" is desirable.
whilst this may be slower initially than a top down mandate, those adapting
to a top down mandate would have to adjust from what they are most
comfortable causing slow down in the future
page 154 of this document presents a diagramatic representaion of a
consensus process:
https://www.radicalroutes.org.uk/wp-content/uploads/woocommerce_uploads/2022/10/How2WorkersCo-op2019A5Lo-Res-pslouz.pdf

In defence of meta discussion, i think meta discussion is really just
discussion where an assumed component is brought back into discussion.

I am new to the project as well, in my experience I have found the mailing
lists to be quite fun, i havent submitted any patches to guix yet so i can
not comment on that
perhaps an alternative could be mailing list propaganda to garner the
excitement that currently surrounds something like discord
one trend i have seen with guix is the tendency to use existing technology
with extensions to achieve ones means instead of using/ developing a
technology which includes all desired features as standard, maybe this is a
function of the older style
the irc and mailing lists are both publically logged and the system-s seem
cohesive
the logs on irc are harder to read than scrolling up in something like
matrix, also the lack of non-text media can be tricky

On Mon, 9 Oct 2023 at 11:29, Tao Hansen <worldofgeese@riseup.net> wrote:

>
> Hello, I hope it's ok I'm replying to this email as a follow-up to
> decreasing the cognitive overhead for new users. I'm also brand new to
> the Guix community and ecosystem. I wanted to share a perspective from a
> user on a Lemmy instance who wrote why the Guix ecosystem was not
> friendly enough to meet them where they were, a person in their early
> twenties. I'd like to suggest approach their criticism with compassion
> and open-mindedness.
>
> @velox_vulnus writes at https://lemmy.ml/comment/4625080
>
> > I don’t like the vibe of ageism against young people that is
> > associated with GNU. What is also frustrating is their reluctance to
> > improve their infrastructure.
>
> > This reason is kind of terrible, I admit, but they could choose to
> > move over to Matrix over IRC, but they choose to be willingly open to
> > spam over having a proper, documented chat channel. I am also
> > reluctant to use my personal mail, for the mailing list. Matrix gives
> > me that anonymity, without also having to geopardize on participation.
> > NixOS is on Matrix, and that’s why I like it. I know Matrix isn’t
> > perfect, but it the better choice between any other messenger.
>
> This user could use an email address dedicated to Guix discussion but
> really I can only agree that sticking to IRC, which requires a lot of
> effort to keep a history log and more effort to host a bouncer makes
> contributing to synchronous discussions difficult. I, myself, am only
> active on the community-run Matrix server and another, less free,
> channel because the overhead is just too high.
>
> > They could choose to remove non-Libre JS from GitLab, Sourcehut or
> > Gitea, or at least come with a new source hosting platform, but they
> > choose not to.
>
> I also have a hard time with the insistence on the "Old Ways" as somehow
> more pure, more legitimate than the new. There's some sense of the
> expression, "You kids get off my lawn!" And the decentralized nature of
> sending Git patches by email, which I still have not ventured to try,
> makes it hard to *discover* Guix development in a single place. A user
> needs to go to any one of the mailing lists, pull the Git repo or browse
> Savannah or the issue frontend for bugs and new features they might be
> interested in, and generally have an idea of what they want to be
> looking for to find it. Discovery by serendipity is missing.
>
> When using the mailing list, even figuring out how to reply to the right
> thread here in Gnus is trying and I'm not even sure if I've done it
> right: people change the subject line, threads grow so large they become
> unmanageable; I had to make sure I CC'd the whole list instead of just
> reply to this mail's author. I still haven't figured out how to stick
> guix-devel in my Gnus home screen: my starting view is always empty
> and I have to remember the shortcut to get to the gigantic overview of
> every Gmane list (this isn't a cry for help).
>
> There's more to their post: I encourage folks to check it out.
>
> We have the FOSS technology to tackle a lot of these critiques and bring
> in a whole new wave of contributors. We have fully open Git forges and
> modern messaging protocols to make a brand new developer-friendly Guix a
> reality.
>
>

[-- Attachment #2: Type: text/html, Size: 7868 bytes --]

Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")

[Kjartan Óli Águstsson]

[-- Attachment #1: Type: text/plain, Size: 3063 bytes --]


Tao Hansen <worldofgeese@riseup.net> writes:

> Hello, I hope it's ok I'm replying to this email as a follow-up to
> decreasing the cognitive overhead for new users. I'm also brand new to
> the Guix community and ecosystem. I wanted to share a perspective from a
> user on a Lemmy instance who wrote why the Guix ecosystem was not
> friendly enough to meet them where they were, a person in their early
> twenties. I'd like to suggest approach their criticism with compassion
> and open-mindedness.

As a person in my early twenties, who has contributed a few (small)
patches to Guix and Emacs, I want to offer another datapoint/perspective
on this issue.

> @velox_vulnus writes at https://lemmy.ml/comment/4625080
>
>> I don’t like the vibe of ageism against young people that is
>> associated with GNU.

I'll be honest, I don't understand this point.  I've never felt any vibe
of ageism from any interaction with the GNU project.  Is this just about
using mailing lists instead of some forge and other similar complaints
of 'outdated' systems/processes?

>> What is also frustrating is their reluctance to improve their
>> infrastructure.

Purely personal anecdote here, but I've never seen a reluctance to
improve infrastructure.  I've seen a reluctance to make changes which
could negatively affect existing workflows, but I wouldn't characterise
that as refusal to improve.

>> They could choose to remove non-Libre JS from GitLab, Sourcehut or
>> Gitea, or at least come with a new source hosting platform, but they
>> choose not to. 
>
> I also have a hard time with the insistence on the "Old Ways" as somehow
> more pure, more legitimate than the new. There's some sense of the
> expression, "You kids get off my lawn!"

Having made contributions to projects using both methods.  I massively
prefer the mailing list + patch workflow of GNU to GitHub's Pull Request
model.

> And the decentralized nature of sending Git patches by email, which I
> still have not ventured to try, makes it hard to *discover* Guix
> development in a single place. A user needs to go to any one of the
> mailing lists, pull the Git repo or browse Savannah or the issue
> frontend for bugs and new features they might be interested in, and
> generally have an idea of what they want to be looking for to find
> it. Discovery by serendipity is missing.

Where does 'Discovery by serendipity occur on GitHub or the other
forges?  Personally I've never experienced more such discoveries than by
reading threads on the development mailing list of a project.

> We have the FOSS technology to tackle a lot of these critiques and bring
> in a whole new wave of contributors. We have fully open Git forges and
> modern messaging protocols to make a brand new developer-friendly Guix a
> reality.

How friendly are these Git forges and messaging protocols to the
continued use of existing email based workflows?

-- 
Kjartan Oli Agustsson
GPG Key fingerprint: 4801 0D71 49C0 1DD6 E5FD  6AC9 D757 2FE3 605E E6B0

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 691 bytes --]