Hi, to help new contributors get their first contribution into Guix I think it would be good to do this: 1. create a new private mailing list or mailing alias guix-mentors@gnu.org 2. ask for experienced Guix contributors who are committed to helping new contributors to subscribe to the list 3. update the Contributing section in the manual (and the website) to suggest Cc-ing guix-mentors@gnu.org for a first contribution. 4. have subscribers to guix-mentors@gnu.org “claim” a contribution within 48 hours, to avoid dilution of responsibilit. Every contribution must be acknowledged. Mentors would then not merely review the submission but shepherd it, making necessary modifications and push the adjusted patches as soon as possible. The goal is not to do the usual review but to create quick successes, a great first impression. I recently contributed my first R package to CRAN, and I received an automatic response that a human reviewer would get back to me within x days. This was a great experience, because I didn’t feel like I dropped off a package into the void. Expectations were managed and a process outlined that set the course for the whole interaction. Our track record with regard to review is not great, and that harm first contributors more than anyone else. Having dedicated mentors who agree to responding and claiming a contribution within 48 hours addresses this problem. I cannot commit to reviewing enough patches that come in on guix-patches, but I sure can promise to join the guix-mentors list and take on and shepherd first contributions. What do you think about this? -- Ricardo
Hi, On Wed, 01 Jun 2022 at 22:17, Ricardo Wurmus <rekado@elephly.net> wrote: > What do you think about this? This is a great idea! > 3. update the Contributing section in the manual (and the website) to > suggest Cc-ing guix-mentors@gnu.org for a first contribution. Maybe instead of manually CC-ing guix-mentor@gnu.org, we could have a tiny script on the top of git-send-email which would add X-Debbugs-CC. Cheers, simon
[-- Attachment #1: Type: text/plain, Size: 614 bytes --] zimoun <zimon.toutoune@gmail.com> ezt írta (időpont: 2022. jún. 2., Cs 0:13): > Hi, > > On Wed, 01 Jun 2022 at 22:17, Ricardo Wurmus <rekado@elephly.net> wrote: > > > What do you think about this? > > This is a great idea! > I agree. Having this would be nice. > > > > 3. update the Contributing section in the manual (and the website) to > > suggest Cc-ing guix-mentors@gnu.org for a first contribution. > > Maybe instead of manually CC-ing guix-mentor@gnu.org, we could have a > tiny script on the top of git-send-email which would add X-Debbugs-CC. > > > Cheers, > simon > > > [-- Attachment #2: Type: text/html, Size: 1385 bytes --]
zimoun <zimon.toutoune@gmail.com> writes:
>> 3. update the Contributing section in the manual (and the website) to
>> suggest Cc-ing guix-mentors@gnu.org for a first contribution.
>
> Maybe instead of manually CC-ing guix-mentor@gnu.org, we could have a
> tiny script on the top of git-send-email which would add X-Debbugs-CC.
I had a similar idea of moving this to the server and triggering an
email notification … but I didn’t want to overcomplicate the initial
proposal. It would indeed be better if a new contributor didn’t also
have to remember to Cc us. The email-based workflow is foreign enough
to be confusing already.
--
Ricardo
Hi Ricardo,
On Thu, 02 Jun 2022 at 08:17, Ricardo Wurmus <rekado@elephly.net> wrote:
> I had a similar idea of moving this to the server and triggering an
> email notification … but I didn’t want to overcomplicate the initial
> proposal. It would indeed be better if a new contributor didn’t also
> have to remember to Cc us. The email-based workflow is foreign enough
> to be confusing already.
I agree.
Ah sorry, I overcomplicate the discussion. :-)
To me, it could be nice to have a tiny script (or Guix extension or
subcommand), maybe in etc/ which simplifies the workflow; something
similar to ’etc/committer.scm’.
The workflow would be:
$ edit code
$ git commit
$ etc/mentoring.scm
where etc/mentoring would generate the patch(es), add X-Debbugs-CC and
send; assuming a correct ~/.gitconfig. And maybe this script could
provide a simple hint for configuring git-send-email.
Even, we could imagine that this tiny script would hint the user to run
“guix lint” or “guix style” before pressing yes at the send step.
From my experience, the most confusing is the “wait from Debbugs ID”
part, i.e., check your inbox or spam. And I do not know how it could be
simplified.
Cheers,
simon
zimoun <zimon.toutoune@gmail.com> writes: > Ah sorry, I overcomplicate the discussion. :-) Hah, no worries! It’s worth discussing this before we implement a workflow that ends up being *more* confusing than the status quo. > To me, it could be nice to have a tiny script (or Guix extension or > subcommand), maybe in etc/ which simplifies the workflow; something > similar to ’etc/committer.scm’. > > The workflow would be: > > $ edit code > $ git commit > $ etc/mentoring.scm > > where etc/mentoring would generate the patch(es), add X-Debbugs-CC and > send; assuming a correct ~/.gitconfig. And maybe this script could > provide a simple hint for configuring git-send-email. > > Even, we could imagine that this tiny script would hint the user to run > “guix lint” or “guix style” before pressing yes at the send step. All good ideas, though I think setting up “git send-email” is a pretty big problem for many people — myself included! Would be nice if that could be simplified, too. > From my experience, the most confusing is the “wait from Debbugs ID” > part, i.e., check your inbox or spam. And I do not know how it could be > simplified. Yes, on top of that comes the gray-listing, which increases the waiting time. Perhaps… we shouldn’t use Debbugs directly. I have a couple of annoyances with Debbugs, including the fact that we cannot configure the contents of the emails it sends out. Maybe it is time to implement a friendlier email-based frontend… -- Ricardo
Hello,
Ricardo Wurmus <rekado@elephly.net> skribis:
> Mentors would then not merely review the submission but shepherd it,
> making necessary modifications and push the adjusted patches as soon as
> possible. The goal is not to do the usual review but to create
> quick successes, a great first impression.
I’m all for it, count me in!
I try to favor newcomers when I go through the guix-patches backlog;
this guix-mentors list will allow us to be more efficient and to share
the workload.
When do we start? :-)
And yes, we should talk about getting fancier once the basics are in
place.
Thanks,
Ludo’.
Hi Ricardo, Perhaps I missed something in your email, but I have a question. Is this new guix-mentors mailing list open to all contributions or only to first-time contributions? If there are too many contributions sent to guix-mentors, how do we manage the workload? Regards, Arun
Arun Isaac <arunisaac@systemreboot.net> writes:
> Perhaps I missed something in your email, but I have a question. Is this
> new guix-mentors mailing list open to all contributions or only to
> first-time contributions? If there are too many contributions sent to
> guix-mentors, how do we manage the workload?
This depends on the number of mentors who commit to claiming
contributions. But my idea was to have this list open to *new*
contributors.
--
Ricardo
Ludovic Courtès <ludo@gnu.org> writes: > Hello, > > Ricardo Wurmus <rekado@elephly.net> skribis: > >> Mentors would then not merely review the submission but shepherd it, >> making necessary modifications and push the adjusted patches as soon as >> possible. The goal is not to do the usual review but to create >> quick successes, a great first impression. > > I’m all for it, count me in! Yay! > I try to favor newcomers when I go through the guix-patches backlog; > this guix-mentors list will allow us to be more efficient and to share > the workload. > > When do we start? :-) Right now, if you want! Though, I guess it would be best for us to gather a few more volunteer for that list. I’ve created a new alias on fencepost.gnu.org, which currently forwards mails to you and me only. Who else wants to join? The requirements: - you have commit access - you will try to claim a new contribution within 48 hours, Cc-ing guix-mentors@gnu.org - you will try to reshape the contribution as needed to make it ready for inclusion in Guix (don’t make the new contributor send revisions) Let me know and I’ll update the mail alias. -- Ricardo
Hi Ricardo,
Ricardo Wurmus <rekado@elephly.net> writes:
> Hi,
>
> to help new contributors get their first contribution into Guix I think
> it would be good to do this:
>
> 1. create a new private mailing list or mailing alias guix-mentors@gnu.org
>
> 2. ask for experienced Guix contributors who are committed to helping
> new contributors to subscribe to the list
>
> 3. update the Contributing section in the manual (and the website) to
> suggest Cc-ing guix-mentors@gnu.org for a first contribution.
>
> 4. have subscribers to guix-mentors@gnu.org “claim” a contribution
> within 48 hours, to avoid dilution of responsibilit. Every contribution
> must be acknowledged.
>
> Mentors would then not merely review the submission but shepherd it,
> making necessary modifications and push the adjusted patches as soon as
> possible. The goal is not to do the usual review but to create
> quick successes, a great first impression.
>
> I recently contributed my first R package to CRAN, and I received an
> automatic response that a human reviewer would get back to me within x
> days. This was a great experience, because I didn’t feel like I dropped
> off a package into the void. Expectations were managed and a process
> outlined that set the course for the whole interaction.
>
> Our track record with regard to review is not great, and that harm first
> contributors more than anyone else. Having dedicated mentors who agree
> to responding and claiming a contribution within 48 hours addresses this
> problem.
>
> I cannot commit to reviewing enough patches that come in on
> guix-patches, but I sure can promise to join the guix-mentors list and
> take on and shepherd first contributions.
Great initiative! The merit of it compared to doing the same on
guix-patches seem to be to more easily notice about new contributions,
and have them in smaller volumes so to offer prompter feedback.
We'd have to define what are 'new contributors' clearly so that it
doesn't get flooded/abused though, since the "review" happens behind
closed doors (in private).
Thanks,
Maxim
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
> We'd have to define what are 'new contributors' clearly so that it
> doesn't get flooded/abused though, since the "review" happens behind
> closed doors (in private).
I’d still want to have the patches hit guix-patches and the changes made
by a mentor detailed there. guix-mentors is meant primarily as a
coordination space for mentors — it’s how new contributors get a
personal mentor for the journey from raw contribution to merge.
--
Ricardo
Am Mittwoch, dem 01.06.2022 um 22:17 +0200 schrieb Ricardo Wurmus:
> Hi,
>
> to help new contributors get their first contribution into Guix I
> think it would be good to do this:
>
> 1. create a new private mailing list or mailing alias
> guix-mentors@gnu.org
>
> 2. ask for experienced Guix contributors who are committed to helping
> new contributors to subscribe to the list
>
> 3. update the Contributing section in the manual (and the website) to
> suggest Cc-ing guix-mentors@gnu.org for a first contribution.
>
> 4. have subscribers to guix-mentors@gnu.org “claim” a contribution
> within 48 hours, to avoid dilution of responsibilit. Every
> contribution must be acknowledged.
>
> [...]
>
> What do you think about this?
As a specific measure against potential abuse as well as a way of
helping out newcomers, what if instead of making new contributors CC
guix-mentors, we made it so that forwarding to guix-mentors is handled
by the spam filter? That is once it's established that a new
contribution is actually a contribution, the patch is forwarded
separately to guix-mentors (along with reply-to: for the original bug
etc. set up in a way that's useful to mentors), claiming takes place,
and so on.
Cheers
June 2, 2022 4:00 AM, "Ricardo Wurmus" <rekado@elephly.net> wrote: > zimoun <zimon.toutoune@gmail.com> writes: > >> Ah sorry, I overcomplicate the discussion. :-) > > Hah, no worries! It’s worth discussing this before we implement a > workflow that ends up being *more* confusing than the status quo. > >> To me, it could be nice to have a tiny script (or Guix extension or >> subcommand), maybe in etc/ which simplifies the workflow; something >> similar to ’etc/committer.scm’. >> >> The workflow would be: >> >> $ edit code >> $ git commit >> $ etc/mentoring.scm >> >> where etc/mentoring would generate the patch(es), add X-Debbugs-CC and >> send; assuming a correct ~/.gitconfig. And maybe this script could >> provide a simple hint for configuring git-send-email. >> >> Even, we could imagine that this tiny script would hint the user to run >> “guix lint” or “guix style” before pressing yes at the send step. > > All good ideas, though I think setting up “git send-email” is a pretty > big problem for many people — myself included! Would be nice if that > could be simplified, too. I always use this website to remind myself how to use git send-email: https://git-send-email.io/ We could out that information in the guix manual or link to it. :) > >> From my experience, the most confusing is the “wait from Debbugs ID” >> part, i.e., check your inbox or spam. And I do not know how it could be >> simplified. > > Yes, on top of that comes the gray-listing, which increases the waiting > time. > > Perhaps… we shouldn’t use Debbugs directly. I have a couple of > annoyances with Debbugs, including the fact that we cannot configure the > contents of the emails it sends out. Maybe it is time to implement a > friendlier email-based frontend… > > -- > Ricardo
Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> writes:
> As a specific measure against potential abuse as well as a way of
> helping out newcomers, what if instead of making new contributors CC
> guix-mentors, we made it so that forwarding to guix-mentors is handled
> by the spam filter? That is once it's established that a new
> contribution is actually a contribution, the patch is forwarded
> separately to guix-mentors (along with reply-to: for the original bug
> etc. set up in a way that's useful to mentors), claiming takes place,
> and so on.
I wouldn’t know how to set this up, but if you have an idea, I’d be
happy to see it implemented.
--
Ricardo
[-- Attachment #1: Type: text/plain, Size: 461 bytes --] Hi Lily, Liliana Marie Prikler 写道: > That is once it's established that a new > contribution is actually a contribution, the patch is forwarded > separately to guix-mentors (along with reply-to: for the > original bug > etc. set up in a way that's useful to mentors), claiming takes > place, > and so on. I have trouble parsing this. Can you highlight the difference(s) with the existing Guix lists, if any? Kind regards, T G-R [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 247 bytes --]
Hi Tobias,
Am Freitag, dem 03.06.2022 um 13:21 +0200 schrieb Tobias Geerinckx-
Rice:
> Hi Lily,
>
> Liliana Marie Prikler 写道:
> > That is once it's established that a new
> > contribution is actually a contribution, the patch is forwarded
> > separately to guix-mentors (along with reply-to: for the
> > original bug etc. set up in a way that's useful to mentors),
> > claiming takes place, and so on.
>
> I have trouble parsing this.
>
> Can you highlight the difference(s) with the existing Guix lists,
> if any?
So first things first, this would only apply to guix-patches (I
believe), since that is where "contributions" as in "patches that need
review" are sent to. My proposal is roughly as follows:
1. When a new contributor sends a mail to guix-patches, the mail gets
added to a manual approval queue. (This currently happens)
2. A human operator manually approves of the patch as in flags it as
"Not spam" (This currently happens)
3. A new issue number is claimed in debbugs, yadda yadda.
4. Since we know (from 1+2), that this is a new contributor, a separate
message is sent to guix-mentors (from debbugs or what have you)
informing mentors about this contribution.
My proposal is to have step 4 implemented in software, sitting in
debbugs, the approval queue software, or possibly both depending on how
much interaction they need, rather than reminding potential newcomers
that guix-mentors exists and that they should CC it to get faster code
review.
Alternatively to the above, which would (in theory) forward the patches
as soon as improved, we could implement this with a separate backend
such as mumi, which would basically check for new patches, check
whether any of those patches come from hitherto unknown sources, and if
so send a mail towards guix-mentors.
Does that help clear things up?
As for guix-mentors vs. other mailing lists, refer to Ricardo's initial
proposal. Interestingly, zimoun had a similar idea, but phrased it
less wordy.
Cheers
[-- Attachment #1: Type: text/plain, Size: 987 bytes --] Liliana Marie Prikler 写道: > So first things first, this would only apply to guix-patches (I > believe), since that is where "contributions" as in "patches > that need > review" are sent to. My proposal is roughly as follows: > 1. When a new contributor sends a mail to guix-patches, the mail > gets > added to a manual approval queue. (This currently happens) > 2. A human operator manually approves of the patch as in flags > it as > "Not spam" (This currently happens) > 3. A new issue number is claimed in debbugs, yadda yadda. It's actually 3, 1, 2 (yeah). > Does that help clear things up? Yes! Thank you. > As for guix-mentors vs. other mailing lists, refer to Ricardo's > initial > proposal. Interestingly, zimoun had a similar idea, but phrased > it > less wordy. So we replace the alias with a proper list? (I'd already asked the sysadmins to create a list, but cancelled it when I noticed the alias.) Kind regards, T G-R [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 247 bytes --]
Hi, On Fri, 03 Jun 2022 at 13:48, Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> wrote: > 1. When a new contributor sends a mail to guix-patches, the mail gets > added to a manual approval queue. (This currently happens) > 2. A human operator manually approves of the patch as in flags it as > "Not spam" (This currently happens) > 3. A new issue number is claimed in debbugs, yadda yadda. > 4. Since we know (from 1+2), that this is a new contributor, a separate > message is sent to guix-mentors (from debbugs or what have you) > informing mentors about this contribution. IIUC, “new contributors” mean «first time to guix-patches»; when I could send a (simple) R package and asking some mentoring and then send another (more complex) package and also asking some mentoring. Such approach is indeed a good way for catching first time contributor – and it appears a good thing to catch. :-) > Alternatively to the above, which would (in theory) forward the patches > as soon as improved, we could implement this with a separate backend > such as mumi, which would basically check for new patches, check > whether any of those patches come from hitherto unknown sources, and if > so send a mail towards guix-mentors. Since it is #3, #1 and #2, indeed this step #4 would be a forward. Well, I do not know how automatic it could be and how extra much work it puts on the shoulder of the human operator (1+2) – already busy enough. :-) > As for guix-mentors vs. other mailing lists, refer to Ricardo's initial > proposal. Interestingly, zimoun had a similar idea, but phrased it > less wordy. My proposal is that the contributor wanting a mentor uses a specific tools for sending to guix-patches; tool which uses internal of Debbugs (X-Debbugs-CC) triggering the CC at step #3. Cheers, simon
Hey!
Ricardo Wurmus <rekado@elephly.net> skribis:
> I’d still want to have the patches hit guix-patches and the changes made
> by a mentor detailed there. guix-mentors is meant primarily as a
> coordination space for mentors — it’s how new contributors get a
> personal mentor for the journey from raw contribution to merge.
So contributors themselves do not need to know about guix-mentors,
right? (My initial understanding was that they’d explicitly email
guix-mentors in addition to guix-patches.)
Ludo’.
Ludovic Courtès <ludo@gnu.org> writes:
> Hey!
>
> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> I’d still want to have the patches hit guix-patches and the changes made
>> by a mentor detailed there. guix-mentors is meant primarily as a
>> coordination space for mentors — it’s how new contributors get a
>> personal mentor for the journey from raw contribution to merge.
>
> So contributors themselves do not need to know about guix-mentors,
> right? (My initial understanding was that they’d explicitly email
> guix-mentors in addition to guix-patches.)
Your initial understanding is correct.
If we can automate the involvement of guix-mentors somehow that would be
nice, of course, but the idea as presented involves new contributors
explicitly CC-ing guix-mentors.
--
Ricardo
Hello,
Ricardo Wurmus <rekado@elephly.net> writes:
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> We'd have to define what are 'new contributors' clearly so that it
>> doesn't get flooded/abused though, since the "review" happens behind
>> closed doors (in private).
>
> I’d still want to have the patches hit guix-patches and the changes made
> by a mentor detailed there. guix-mentors is meant primarily as a
> coordination space for mentors — it’s how new contributors get a
> personal mentor for the journey from raw contribution to merge.
I see! Thanks for the clarification.
Maxim
On 03/06/2022 12:53, jbranso@dismail.de wrote:
> I always use this website to remind myself how to use git send-email:
> https://git-send-email.io/
>
> We could out that information in the guix manual or link to it. :)
This is great - many thanks for sharing. I think a link in the manual
would be very useful.
Hi, What is the status of this initiative? On Wed, 01 Jun 2022 at 22:17, Ricardo Wurmus <rekado@elephly.net> wrote: > to help new contributors get their first contribution into Guix I think > it would be good to do this: > > 1. create a new private mailing list or mailing alias guix-mentors@gnu.org > > 2. ask for experienced Guix contributors who are committed to helping > new contributors to subscribe to the list > > 3. update the Contributing section in the manual (and the website) to > suggest Cc-ing guix-mentors@gnu.org for a first contribution. > > 4. have subscribers to guix-mentors@gnu.org “claim” a contribution > within 48 hours, to avoid dilution of responsibilit. Every contribution > must be acknowledged. [...] > What do you think about this? We all agree it is a good idea and it could smooth the first time experience. Therefore, how do we process next? Cheers, simon
zimoun <zimon.toutoune@gmail.com> writes: > What is the status of this initiative? Only two people have come forward as possible mentors (Ludo and I). With only two potential mentors there’s no point in doing this as it’s not sustainable. > Therefore, how do we process next? We wait for volunteers. And if it turns out that there are not enough volunteers we bury the idea. -- Ricardo
Hi,
On Wed, 22 Jun 2022 at 11:44, Ricardo Wurmus <rekado@elephly.net> wrote:
> Only two people have come forward as possible mentors (Ludo and I).
> With only two potential mentors there’s no point in doing this as it’s
> not sustainable.
Add me as possible mentor. Well, I do not know if I am enough qualified
for complex patches but I can surely help for simple ones.
Cheers,
simon
Hey there! Surely we can get more than three volunteers for mentoring; the more we are, the less work any one of us will have to do. Who’s in? I could name a bunch of people who’ve been helping submitters a lot—you know who you are :-)—and this is just the same thing we’re trying to formalize here. Ludo’.
Hi, On Wed, Jun 22, 2022 at 6:26 AM Ludovic Courtès <ludo@gnu.org> wrote: > > Surely we can get more than three volunteers for mentoring; Maybe the word mentor is a turn-off? It suggests a longer-term relationship where none need exist. How about calling it a "patch pilot" (or a "commit pilot") who would assist more like a harbor pilot? [1] Kind regards, Felix Lechner [1] https://en.wikipedia.org/wiki/Maritime_pilot
Hello,
Ludovic Courtès <ludo@gnu.org> writes:
> Hey there!
>
> Surely we can get more than three volunteers for mentoring; the more we
> are, the less work any one of us will have to do.
>
> Who’s in?
>
> I could name a bunch of people who’ve been helping submitters a lot—you
> know who you are :-)—and this is just the same thing we’re trying to
> formalize here.
I didn't throw my hat into the ring because I'm not a committer (the
first requirement in the list). I can work on a patch until it's fit for
committing and poke someone else to commit for me. Would that help?
--
Thanks
Thiago