Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")
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 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 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 signature.asc Description: PGP signature
Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")
Hi, On Mon, 09 Oct 2023 at 12:29, Katherine Cox-Buday 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?")
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
Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")
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 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
Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")
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?")
Hi Katherine, Katherine Cox-Buday 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
Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")
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
Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")
Hi Simon, Simon Tournier 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
Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")
Hi, Really cool! Thank you. On Sat, 16 Sep 2023 at 14:59, Wilko Meyer 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 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?")
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
Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")
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
