Re: Insights for future development from the Guix Survey

[45mg]

Hi jbranso,

jbra...@dismail.de writes:

>> In general, the current work-flow and ethos within the team seems to favour 
>> incremental changes. Perhaps it's due to being volunteer-driven but I've 
>> seen multiple big patch-sets get to about 90% and then never make it over 
>> the line.
>> 
>> The number one reason for this, is the problem of a constrained contribution 
>> review process. I guess 'big' series will be deprioritised if it's not the 
>> reviewers specialist area.
>> 
>> Big changes need a group to work together, we have 'teams' (bit nascent) - 
>> but maybe we need some other way to highlight big changes and rally people 
>> together?
>
> Perhaps we could write a blog post? To highlight some of those things?
> Maybe we can encourage someone to look at those various patches, or
> at least have a record of cool patches that need review.
> Something like:
>
> Merging Guix's unfixed patches
>
> Guix is a significant free software project, and it has lots of really
> cool featured that are almost done.  Perhaps you would like to help us
> get these accross the finish line?
>
> - support for testing php packages:  https://issues.guix.gnu.org/67902
> - opensmtpd-service-type  (my fault it's not finished) 
> https://issues.guix.gnu.org/56046
> - new bootloader code that is not grub-specific  
> https://issues.guix.gnu.org/72457
> - package phosh ( https://issues.guix.gnu.org/44400 )
>
> blah blah blah
>
> If a blog post is a bad idea, then maybe we could add those cool patches
> to the TODO.org file?

I recently conducted a small survey on guix-devel, to get people's
opinions on sending pings to neglected patches:

https://lists.gnu.org/r/guix-devel/2025-01/msg00209.html

Of note here, there was a fair amount of interest in having a dedicated
place to send pings (eg. a separate thread or mailing-list).

I'm thinking this could help collect unreviewed work in one place so
that everyone who wants to can see it. Additionally, the fact that
someone has submitted a patch to such a thread/list would signify that
they're still ready to respond to review, send new versions, etc., which
is often not clear with patches that have simply gone silent after
months.

For an example of this, NixOS has monthly 'PRs ready for review' threads
on their Discourse, where people can post theirs:

https://discourse.nixos.org/t/prs-ready-for-review-december/1711

Survey Results: Pinging Neglected Patches (was: Survey: Pinging Neglected Patches)

[45mg]

Hi Guix,

In this message are the results of the above survey.

In total, there were 22 complete responses to this survey (LimeSurvey
would only have allowed a total of 25 on a free plan anyway), and 13
'incomplete' ones (seems like it counted people who clicked on the
survey but didn't fill it). So bear in mind that the sample size here is
quite small. The survey ran for 10 days (01/17/25 - 01/27/25).

Both questions were 'select all that apply' multiple-choice questions,
with an 'Other' option that allowed free-form text input.




--8<---cut here---start->8---

Where can/should a ping be sent?


Answer   Count   
Percentage
 --- 

Don 't send pings at all 3   8.57%
To the Debbugs address for the patch (eg. 12...@debbugs.gnu.org) 17  48.57%
To the Guix-Devel mailing list   6   17.14%
To a dedicated thread or list meant for pings (hypothetical) 8   22.86%
Other5   14.29%
Not completed or Not displayed   13  37.14%

'Other' responses:

ID   Response
 
6IRC
8to team members maintaining the affected packages
9To dedicated maintainers for the series (as per CC or teams.scm); to IRC
 or similar channels
20   You could send it directly to the reviewer, if your relationship with
 them makes you think it would be effective. It really depends on the
 reasons that the review is delayed and the patch submitter needs to make
 at least some effort to understand that context.
22   to one of the commiters via IRC (politely)




How long should a contributor wait before sending a ping?
=

Answer  Count   Percentage
--- --- 
Don 't send pings at all2   5.71%
After a year0   0.00%
After six months2   5.71%
After a month   10  28.57%
After two weeks 9   25.71%
After a week3   8.57%
After three days0   0.00%
After one day   0   0.00%
Other   2   5.71%
Not completed or Not displayed  13  37.14%

'Other' responses:

ID   Response
 -
20   It depends on the situation.
30   A week but it depends on volume of emails in the list

--8<---cut here---end--->8---




The plain-text tables seen above were generated by exporting the results
from LimeSurvey as .xlsx (the 'Excel' export option), saving that as
.csv via LibreOffice, converting sections of the .csv file to Markdown
tables via Pandoc, and finally, painstakingly cleaning up whitespace and
alignment by hand in Emacs. (As you might have gathered, this was a
ridiculous amount of work. Maybe I should've just done the lazy thing
and attached the PDF export...)

Side note - LimeSurvey has the worst UX of any web app I've ever used. I
do NOT want to touch that thing ever again. Would not recommend.
(Apparently Cryptpad has a Google Forms equivalent, in case anyone else
is thinking of doing something like this.)

Thank you to everyone who responded,
45mg

45mg <45mg.wri...@gmail.com> writes:

> Hi Guix,
>
> I have seen different opinions [1][2] regarding sending pings to patches
> that aren't getting reviewed or are otherwise lacking attention.
>
> To get a better idea of peoples' opinions, I've created a survey. Please
> do take it, it's only two questions long.
>
> https://sneakmonkey.limesurvey.net/286966?lang=en
>
> I think it would be good for Guix to have stated guidelines on this
> subject, so that everybody knows in advance what is considered
> acceptable and what isn't. Right now it is difficult for a new
> contributor to judge whether sending a ping will help or not. Hopefully
> the survey is a step in the right direction.
>
> Thanks,
> 45mg
>
> P.S. Regarding the option 'To a dedicated thread or list meant for pings
> (hypothetical)': I was thinking along the lines of NixOS's monthly 'PRs
> ready for review' threads [3].
>
> [1] https://lists.gnu.org/archive/html/guix-devel/2025-01/msg00072.html
> [2] https://lists.gnu.org/archive/html/guix-devel/2025-01/msg00100.html
> [3] https://discourse.nixos.org/t/prs-ready-for-review-december/1711

Re: Insights for future development from the Guix Survey

[Suhail Singh]

45mg <45mg.wri...@gmail.com> writes:

> I'm thinking this could help collect unreviewed work in one place so
> that everyone who wants to can see it.

For your situational awareness, note that one such place already exists
to an extent today.  The usertag "patch-review-hackers-list" has been
used by some to get some attention to existing issues awaiting review.

I'm not arguing against having another mechanism (in its stead) to
denote items in need of review, I'm merely advocating that we consider
any such mechanism in relation to the current options today.

-- 
Suhail

Re: Insights for future development from the Guix Survey

[Suhail Singh]

jbra...@dismail.de writes:

> What is "patch-review-hackers-list" ?  Can you send me some documentation
> on how to use it?

It's one of a few tags that the london guix meetup has used in the past.
See 
for details, including other related usertags such as
escalated-review-request.

In terms of how to review the list of packages with a given usertag,
debbugs.el in Emacs provides M-x debbugs-gnu-usertags.

-- 
Suhail

Re: Insights for future development from the Guix Survey

[jbranso]

January 27, 2025 at 12:35 PM, "Suhail Singh" mailto:suhailsingh...@gmail.com?to=%22Suhail%20Singh%22%20%3Csuhailsingh247%40gmail.com%3E
 > wrote:



> 
> 45mg <45mg.wri...@gmail.com> writes:
> 
> > 
> > I'm thinking this could help collect unreviewed work in one place so
> >  that everyone who wants to can see it.
> > 
> For your situational awareness, note that one such place already exists
> to an extent today. The usertag "patch-review-hackers-list" has been
> used by some to get some attention to existing issues awaiting review.

What is "patch-review-hackers-list" ?  Can you send me some documentation
on how to use it?

> 
> I'm not arguing against having another mechanism (in its stead) to
> denote items in need of review, I'm merely advocating that we consider
> any such mechanism in relation to the current options today.
> 
> -- 
> Suhail
>