unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Formalizing teams
@ 2021-12-22 15:46 Ludovic Courtès
  2021-12-22 16:04 ` Jack Hill
                   ` (2 more replies)
  0 siblings, 3 replies; 21+ messages in thread
From: Ludovic Courtès @ 2021-12-22 15:46 UTC (permalink / raw)
  To: Guix Devel

Hello Guix!

I’ve been looking at our guix-patches backlog, at the great
contributions we get but that stick there for too long, certainly
discouraging people, and also at non-code initiatives (meetups, Guix
Days, Outreachy, documentation, etc.) that we as a project could often
support and encourage better, wondering how we could improve.

I’ve been inspired by how the Rust folks approach these issues, in
particular as described here:

  https://blog.m-ou.se/rust-is-not-a-company/

  https://www.youtube.com/watch?v=T1t4zGJYUuY
    (RacketCon 2019 talk by Aaron Turon)

One idea that I like is to bring structure to the group, or rather to
make structure visible, so that newcomers know who they can talk to to
get started on a topic, know who to ping for reviews, and so that each
one of us can see where they fit.  Rust has well-defined teams:

  https://www.rust-lang.org/governance

Guix is nowhere near the size of the Rust community (yet!), but I can
already picture teams and members:

  co-maintainers (“core team”)
  community
  infrastructure
  internationalization
  security response
  release
  Rust packaging
  R packaging
  Java packaging

In Rust, teams are responsible for overseeing discussions and changes in
their area, but also ultimately for making decisions.  I think that’s
pretty much the case with the informal teams that exist today in Guix,
but that responsibility could be made more explicit here.  They
distinguish teams from “working groups”, where working groups work on
actually implementing what the team decided.

How about starting with a web page listing these teams, their work,
their members, and ways to contact them?  Teams would be the primary
contact point and for things that fall into their area and would be
responsible for channeling proposals and advancing issues in their area.

What do people think?

Aaron Turon nicely explains that at first sight it has a bureaucratic
feel to it, but that in practice it does help a lot in many ways, from
onboarding to channeling change without losing consistency.

Ludo’.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Formalizing teams
  2021-12-22 15:46 Ludovic Courtès
@ 2021-12-22 16:04 ` Jack Hill
  2021-12-22 16:22   ` indieterminacy
  2021-12-22 19:43 ` Filip Łajszczak
  2021-12-27  5:17 ` Maxim Cournoyer
  2 siblings, 1 reply; 21+ messages in thread
From: Jack Hill @ 2021-12-22 16:04 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix Devel

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

On Wed, 22 Dec 2021, Ludovic Courtès wrote:

> Hello Guix!
>
> I’ve been looking at our guix-patches backlog, at the great
> contributions we get but that stick there for too long, certainly
> discouraging people, and also at non-code initiatives (meetups, Guix
> Days, Outreachy, documentation, etc.) that we as a project could often
> support and encourage better, wondering how we could improve.
>
> I’ve been inspired by how the Rust folks approach these issues, in
> particular as described here:
>
>  https://blog.m-ou.se/rust-is-not-a-company/
>
>  https://www.youtube.com/watch?v=T1t4zGJYUuY
>    (RacketCon 2019 talk by Aaron Turon)
>
> One idea that I like is to bring structure to the group, or rather to
> make structure visible, so that newcomers know who they can talk to to
> get started on a topic, know who to ping for reviews, and so that each
> one of us can see where they fit.  Rust has well-defined teams:
>
>  https://www.rust-lang.org/governance
>
> Guix is nowhere near the size of the Rust community (yet!), but I can
> already picture teams and members:
>
>  co-maintainers (“core team”)
>  community
>  infrastructure
>  internationalization
>  security response
>  release
>  Rust packaging
>  R packaging
>  Java packaging
>
> In Rust, teams are responsible for overseeing discussions and changes in
> their area, but also ultimately for making decisions.  I think that’s
> pretty much the case with the informal teams that exist today in Guix,
> but that responsibility could be made more explicit here.  They
> distinguish teams from “working groups”, where working groups work on
> actually implementing what the team decided.
>
> How about starting with a web page listing these teams, their work,
> their members, and ways to contact them?  Teams would be the primary
> contact point and for things that fall into their area and would be
> responsible for channeling proposals and advancing issues in their area.
>
> What do people think?
>
> Aaron Turon nicely explains that at first sight it has a bureaucratic
> feel to it, but that in practice it does help a lot in many ways, from
> onboarding to channeling change without losing consistency.
>
> Ludo’.

+1 from me. I think that it is natural that as we grow (yay!) we'll need a 
little bit more structure. It would be wise to not overdo it and create 
too many teams to start with, but I have nevertheless brainstormed some 
additional teams:

* Documentation/Communication/Cookbook Recipes
* Desktop Environments

Best,
Jack

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Formalizing teams
  2021-12-22 16:04 ` Jack Hill
@ 2021-12-22 16:22   ` indieterminacy
  0 siblings, 0 replies; 21+ messages in thread
From: indieterminacy @ 2021-12-22 16:22 UTC (permalink / raw)
  To: Jack Hill; +Cc: guix-devel

Its certainly worth developing more formal clusters.

It would be wise to try and make concerns and research interconnected -
lest we create silos that communicate with other groups less.


Jonathan McHugh

Jack Hill <jackhill@jackhill.us> writes:

> On Wed, 22 Dec 2021, Ludovic Courtès wrote:
>
>> Hello Guix!
>>
>> I’ve been looking at our guix-patches backlog, at the great
>> contributions we get but that stick there for too long, certainly
>> discouraging people, and also at non-code initiatives (meetups, Guix
>> Days, Outreachy, documentation, etc.) that we as a project could often
>> support and encourage better, wondering how we could improve.
>>
>> I’ve been inspired by how the Rust folks approach these issues, in
>> particular as described here:
>>
>>  https://blog.m-ou.se/rust-is-not-a-company/
>>
>>  https://www.youtube.com/watch?v=T1t4zGJYUuY
>>    (RacketCon 2019 talk by Aaron Turon)
>>
>> One idea that I like is to bring structure to the group, or rather to
>> make structure visible, so that newcomers know who they can talk to to
>> get started on a topic, know who to ping for reviews, and so that each
>> one of us can see where they fit.  Rust has well-defined teams:
>>
>>  https://www.rust-lang.org/governance
>>
>> Guix is nowhere near the size of the Rust community (yet!), but I can
>> already picture teams and members:
>>
>>  co-maintainers (“core team”)
>>  community
>>  infrastructure
>>  internationalization
>>  security response
>>  release
>>  Rust packaging
>>  R packaging
>>  Java packaging
>>
>> In Rust, teams are responsible for overseeing discussions and changes in
>> their area, but also ultimately for making decisions.  I think that’s
>> pretty much the case with the informal teams that exist today in Guix,
>> but that responsibility could be made more explicit here.  They
>> distinguish teams from “working groups”, where working groups work on
>> actually implementing what the team decided.
>>
>> How about starting with a web page listing these teams, their work,
>> their members, and ways to contact them?  Teams would be the primary
>> contact point and for things that fall into their area and would be
>> responsible for channeling proposals and advancing issues in their area.
>>
>> What do people think?
>>
>> Aaron Turon nicely explains that at first sight it has a bureaucratic
>> feel to it, but that in practice it does help a lot in many ways, from
>> onboarding to channeling change without losing consistency.
>>
>> Ludo’.
>
> +1 from me. I think that it is natural that as we grow (yay!) we'll
> need a little bit more structure. It would be wise to not overdo it
> and create too many teams to start with, but I have nevertheless
> brainstormed some additional teams:
>
> * Documentation/Communication/Cookbook Recipes
> * Desktop Environments
>
> Best,
> Jack



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Formalizing teams
  2021-12-22 15:46 Ludovic Courtès
  2021-12-22 16:04 ` Jack Hill
@ 2021-12-22 19:43 ` Filip Łajszczak
  2022-01-03 15:09   ` Ludovic Courtès
  2021-12-27  5:17 ` Maxim Cournoyer
  2 siblings, 1 reply; 21+ messages in thread
From: Filip Łajszczak @ 2021-12-22 19:43 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

On 22/12/2021 15.46, Ludovic Courtès wrote:
> I’ve been looking at our guix-patches backlog, at the great
> contributions we get but that stick there for too long, certainly
> discouraging people, 

[...]

> One idea that I like is to bring structure to the group, or rather to
> make structure visible, so that newcomers know who they can talk to to
> get started on a topic, know who to ping for reviews, 
Great idea. As a newcomer who created his first patch in May 
https://issues.guix.gnu.org/issue/48289/ that got a review, was fixed 
and submitted again, and then disappeared into oblivion, I would be very 
happy to be able to ask some "Python packaging" team what is wrong with 
my patch. At the same time I'm grateful for everything that is being 
done all the time, so I'm not in a position to put any pressure on 
anyone. (BTW, I resubmitted it in the new style after The Big Change)

Cheers,
Filip


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Formalizing teams
@ 2021-12-23 15:13 Blake Shaw
  2021-12-23 21:51 ` Jonathan McHugh
  0 siblings, 1 reply; 21+ messages in thread
From: Blake Shaw @ 2021-12-23 15:13 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix Devel

Ludovic Courtès <ludo@gnu.org> writes:

> One idea that I like is to bring structure to the group, or rather to
> make structure visible, so that newcomers know who they can talk to to
> get started on a topic, know who to ping for reviews, and so that each
> one of us can see where they fit.  Rust has well-defined teams:
>
>   https://www.rust-lang.org/governance
>
Definitely! Perhaps this an aesthetic matter, but keeping-with the
community spirit of Guix, and the existing nomenclature where the
'core' maintainers are called a "collective", perhaps we should avoid
some of the more corporate "team" language of Rust/Mozilla and stick to
"collectives"?
> In Rust, teams are responsible for overseeing discussions and changes in
> their area, but also ultimately for making decisions.  I think that’s
> pretty much the case with the informal teams that exist today in Guix,
> but that responsibility could be made more explicit here.  They
> distinguish teams from “working groups”, where working groups work on
> actually implementing what the team decided.
>
> How about starting with a web page listing these teams, their work,
> their members, and ways to contact them?  Teams would be the primary
> contact point and for things that fall into their area and would be
> responsible for channeling proposals and advancing issues in their area.
>
> What do people think?

I think it sounds great. The question remains what is the medium-space
where through which the teams interact? How do we prevent teams from
becoming silo'd off from one another? Do we have an "assembly" or an
"assembler"?

Should this become a matter for Guix Days?

-- 
“In girum imus nocte et consumimur igni”


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Formalizing teams
  2021-12-23 15:13 Formalizing teams Blake Shaw
@ 2021-12-23 21:51 ` Jonathan McHugh
  2021-12-24 12:23   ` Hartmut Goebel
  0 siblings, 1 reply; 21+ messages in thread
From: Jonathan McHugh @ 2021-12-23 21:51 UTC (permalink / raw)
  To: Blake Shaw, Ludovic Courtès; +Cc: Guix Devel

December 23, 2021 4:13 PM, "Blake Shaw" <blake@nonconstructivism.com> wrote:

> Ludovic Courtès <ludo@gnu.org> writes:
> 
>> One idea that I like is to bring structure to the group, or rather to
>> make structure visible, so that newcomers know who they can talk to to
>> get started on a topic, know who to ping for reviews, and so that each
>> one of us can see where they fit. Rust has well-defined teams:
>> 
>> https://www.rust-lang.org/governance
> 
> Definitely! Perhaps this an aesthetic matter, but keeping-with the
> community spirit of Guix, and the existing nomenclature where the
> 'core' maintainers are called a "collective", perhaps we should avoid
> some of the more corporate "team" language of Rust/Mozilla and stick to
> "collectives"?
> 

I reckon 'coterie' is more elegant a term:
```
: an intimate and often exclusive group of persons with a unifying common interest or purpose
```


====================
Jonathan McHugh
indieterminacy@libre.brussels


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Formalizing teams
  2021-12-23 21:51 ` Jonathan McHugh
@ 2021-12-24 12:23   ` Hartmut Goebel
  2021-12-24 15:37     ` indieterminacy
  0 siblings, 1 reply; 21+ messages in thread
From: Hartmut Goebel @ 2021-12-24 12:23 UTC (permalink / raw)
  To: Jonathan McHugh, Blake Shaw, Ludovic Courtès; +Cc: Guix Devel

Am 23.12.21 um 22:51 schrieb Jonathan McHugh:
> I reckon 'coterie' is more elegant a term:

IMHO we chould not use this term.

The German translation is "Seilschaft", "Klüngel" - both of which have 
negative meaning: Working together to the benefit of the members of the 
group only - ignoring common interest.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Formalizing teams
  2021-12-24 12:23   ` Hartmut Goebel
@ 2021-12-24 15:37     ` indieterminacy
  0 siblings, 0 replies; 21+ messages in thread
From: indieterminacy @ 2021-12-24 15:37 UTC (permalink / raw)
  To: Hartmut Goebel; +Cc: Guix Devel

Good catch!

TBH, I did wonder whether the feudal eptimology of the English word may
raise eyebrows.

Hartmut Goebel <h.goebel@crazy-compilers.com> writes:

> Am 23.12.21 um 22:51 schrieb Jonathan McHugh:
>> I reckon 'coterie' is more elegant a term:
>
> IMHO we chould not use this term.
>
> The German translation is "Seilschaft", "Klüngel" - both of which have
> negative meaning: Working together to the benefit of the members of
> the group only - ignoring common interest.



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Formalizing teams
  2021-12-22 15:46 Ludovic Courtès
  2021-12-22 16:04 ` Jack Hill
  2021-12-22 19:43 ` Filip Łajszczak
@ 2021-12-27  5:17 ` Maxim Cournoyer
  2021-12-28 10:52   ` Lars-Dominik Braun
  2021-12-28 14:44   ` Ricardo Wurmus
  2 siblings, 2 replies; 21+ messages in thread
From: Maxim Cournoyer @ 2021-12-27  5:17 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix Devel

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Hello Guix!
>
> I’ve been looking at our guix-patches backlog, at the great
> contributions we get but that stick there for too long, certainly
> discouraging people, and also at non-code initiatives (meetups, Guix
> Days, Outreachy, documentation, etc.) that we as a project could often
> support and encourage better, wondering how we could improve.

I think we're not doing too badly considering the tooling we have at our
disposal, but yes, there's definitely room for improvement!

[...]

> One idea that I like is to bring structure to the group, or rather to
> make structure visible, so that newcomers know who they can talk to to
> get started on a topic, know who to ping for reviews, and so that each
> one of us can see where they fit.  Rust has well-defined teams:

I've grown to like our apparent lack of structure; we interact globally
on any topic of interest and the discussions all happen in a shared
space, which makes it easy to stay informed with everything that's going
on (do we really need more mailing lists to follow?  I don't think so --
our current volume doesn't warrant it).

> Guix is nowhere near the size of the Rust community (yet!), but I can
> already picture teams and members:
>
>   co-maintainers (“core team”)
>   community
>   infrastructure
>   internationalization
>   security response
>   release
>   Rust packaging
>   R packaging
>   Java packaging

We'd have to include every language/system of importance to that list
(Python, Ruby, Emacs, LaTeX, Perl, etc.), no?

> In Rust, teams are responsible for overseeing discussions and changes in
> their area, but also ultimately for making decisions.  I think that’s
> pretty much the case with the informal teams that exist today in Guix,
> but that responsibility could be made more explicit here.  They
> distinguish teams from “working groups”, where working groups work on
> actually implementing what the team decided.
>
> How about starting with a web page listing these teams, their work,
> their members, and ways to contact them?  Teams would be the primary
> contact point and for things that fall into their area and would be
> responsible for channeling proposals and advancing issues in their area.
>
> What do people think?

Are our problems really organizational?  I think before attempting to
come up with a solution, we must analyze and agree on what it is that
needs improvement to help us move forward more efficiently.

Thanks for initiating the conversation,

Maxim


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Formalizing teams
  2021-12-27  5:17 ` Maxim Cournoyer
@ 2021-12-28 10:52   ` Lars-Dominik Braun
  2021-12-28 15:44     ` Kyle Meyer
  2021-12-28 14:44   ` Ricardo Wurmus
  1 sibling, 1 reply; 21+ messages in thread
From: Lars-Dominik Braun @ 2021-12-28 10:52 UTC (permalink / raw)
  To: Maxim Cournoyer; +Cc: Guix Devel

Hi Maxim,

> I've grown to like our apparent lack of structure; we interact globally
> on any topic of interest and the discussions all happen in a shared
> space, which makes it easy to stay informed with everything that's going
> on (do we really need more mailing lists to follow?  I don't think so --
> our current volume doesn't warrant it).
to me this is a disadvantage. I don’t have enough time at my hands to
look at every single thread and patch in my inbox and decide whether
I can/want to work on it. Thus I’d prefer if I could unsubscribe
from -patches (I’m not even subscribed to -bug/-commit) and instead
only look at bugs/patches/commits related to packages/components I’m
interested into/I actually use.

To that end having more structure would help. Teams are just one option,
but we need a way to efficiently connect people with skills to review/help
with those who need the review/help. This sounds similar to what
Gentoo’s Bug Wranglers[1] do. I believe someone brought up to automate
this by suggesting reviewers for patches based on the commit history
of packages/components.

[1] https://wiki.gentoo.org/wiki/Project:Bug-wranglers

Cheers,
Lars



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Formalizing teams
  2021-12-27  5:17 ` Maxim Cournoyer
  2021-12-28 10:52   ` Lars-Dominik Braun
@ 2021-12-28 14:44   ` Ricardo Wurmus
  2021-12-29  9:05     ` Efraim Flashner
  2022-01-03 15:22     ` Ludovic Courtès
  1 sibling, 2 replies; 21+ messages in thread
From: Ricardo Wurmus @ 2021-12-28 14:44 UTC (permalink / raw)
  To: Maxim Cournoyer; +Cc: guix-devel


Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

>> Guix is nowhere near the size of the Rust community (yet!), but I can
>> already picture teams and members:
>>
>>   co-maintainers (“core team”)
>>   community
>>   infrastructure
>>   internationalization
>>   security response
>>   release
>>   Rust packaging
>>   R packaging
>>   Java packaging
>
> We'd have to include every language/system of importance to that list
> (Python, Ruby, Emacs, LaTeX, Perl, etc.), no?

No, only those where we already have the people who could form a team.
There is no need for any of this to be comprehensive.  It just needs to
be an improvement over the status quo.

FWIW, I’ll gladly make it official that I could be the person to talk to
when it comes to “R packaging”.  This is already the case, but only
those people know it who don’t really need to know this.

Advertising this kind of information or recording it somewhere where our
tools could redirect incoming requests would be an improvement.

> Are our problems really organizational?  I think before attempting to
> come up with a solution, we must analyze and agree on what it is that
> needs improvement to help us move forward more efficiently.

I do think it’s a lack of organization, yes.  Today I’m no longer
following guix-commits, guix-patches, or bug-guix, and I’m overwhelmed
by guix-devel and help-guix.  Whenever something catches my attention
I’ll read a bit and maybe reply.  But by far the best way to get my
attention for a review is to ask on #guix or #guix-hpc or to
X-Debbugs-Cc (or Cc) me on emails.

Having some topic-specific streams I could tap into would allow me to be
a little more proactive.

-- 
Ricardo


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Formalizing teams
  2021-12-28 10:52   ` Lars-Dominik Braun
@ 2021-12-28 15:44     ` Kyle Meyer
  2021-12-28 18:03       ` Ricardo Wurmus
  0 siblings, 1 reply; 21+ messages in thread
From: Kyle Meyer @ 2021-12-28 15:44 UTC (permalink / raw)
  To: Lars-Dominik Braun; +Cc: Guix Devel, Maxim Cournoyer

Lars-Dominik Braun writes:

> Hi Maxim,
>
>> I've grown to like our apparent lack of structure; we interact globally
>> on any topic of interest and the discussions all happen in a shared
>> space, which makes it easy to stay informed with everything that's going
>> on (do we really need more mailing lists to follow?  I don't think so --
>> our current volume doesn't warrant it).
> to me this is a disadvantage. I don’t have enough time at my hands to
> look at every single thread and patch in my inbox and decide whether
> I can/want to work on it. Thus I’d prefer if I could unsubscribe
> from -patches (I’m not even subscribed to -bug/-commit) and instead
> only look at bugs/patches/commits related to packages/components I’m
> interested into/I actually use.

Fwiw public-inbox indexes the file name from diffs, so you might find
searching with the "dfn:" against the archive at
<https://yhetil.org/guix-patches> useful.  For example:

  https://yhetil.org/guix-patches/?q=dfn%3Agnu%2Fpackages%2Fpython-web.scm

Or with public-inbox's lei (from v1.7.0, which isn't yet packaged for
Guix), you could dump those results to a maildir:

  $ lei q -o /tmp/mdir --mua mutt \
    -I https://yhetil.org/guix-patches dfn:gnu/packages/python-web.scm d:4.months.ago..
  # later: update with new results and visit in mutt
  $ lei up --mua mutt /tmp/mdir

If you're interested, I went into a bit more detail about this at
<https://yhetil.org/guix/87a6izsoio.fsf@kyleam.com/>.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Formalizing teams
  2021-12-28 15:44     ` Kyle Meyer
@ 2021-12-28 18:03       ` Ricardo Wurmus
  2021-12-29 21:04         ` Lars-Dominik Braun
  0 siblings, 1 reply; 21+ messages in thread
From: Ricardo Wurmus @ 2021-12-28 18:03 UTC (permalink / raw)
  To: Kyle Meyer; +Cc: guix-devel, Maxim Cournoyer


Kyle Meyer <kyle@kyleam.com> writes:

> Fwiw public-inbox indexes the file name from diffs, so you might find
> searching with the "dfn:" against the archive at
> <https://yhetil.org/guix-patches> useful.  For example:
>
>   https://yhetil.org/guix-patches/?q=dfn%3Agnu%2Fpackages%2Fpython-web.scm

FWIW, mumi also lets you search patches as all contents are indexed:

    https://issues.guix.gnu.org/search?query=%22%28gnu+packages+python-web%29%22+is%3Aopen+tag%3Apatch

-- 
Ricardo


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Formalizing teams
  2021-12-28 14:44   ` Ricardo Wurmus
@ 2021-12-29  9:05     ` Efraim Flashner
  2022-01-03 15:22     ` Ludovic Courtès
  1 sibling, 0 replies; 21+ messages in thread
From: Efraim Flashner @ 2021-12-29  9:05 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel, Maxim Cournoyer

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

On Tue, Dec 28, 2021 at 03:44:55PM +0100, Ricardo Wurmus wrote:
> 
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
> 
> >> Guix is nowhere near the size of the Rust community (yet!), but I can
> >> already picture teams and members:
> >>
> >>   co-maintainers (“core team”)
> >>   community
> >>   infrastructure
> >>   internationalization
> >>   security response
> >>   release
> >>   Rust packaging
> >>   R packaging
> >>   Java packaging
> >
> > We'd have to include every language/system of importance to that list
> > (Python, Ruby, Emacs, LaTeX, Perl, etc.), no?
> 
> No, only those where we already have the people who could form a team.
> There is no need for any of this to be comprehensive.  It just needs to
> be an improvement over the status quo.
> 
> FWIW, I’ll gladly make it official that I could be the person to talk to
> when it comes to “R packaging”.  This is already the case, but only
> those people know it who don’t really need to know this.
> 
> Advertising this kind of information or recording it somewhere where our
> tools could redirect incoming requests would be an improvement.
> 
> > Are our problems really organizational?  I think before attempting to
> > come up with a solution, we must analyze and agree on what it is that
> > needs improvement to help us move forward more efficiently.
> 
> I do think it’s a lack of organization, yes.  Today I’m no longer
> following guix-commits, guix-patches, or bug-guix, and I’m overwhelmed
> by guix-devel and help-guix.  Whenever something catches my attention
> I’ll read a bit and maybe reply.  But by far the best way to get my
> attention for a review is to ask on #guix or #guix-hpc or to
> X-Debbugs-Cc (or Cc) me on emails.
> 
> Having some topic-specific streams I could tap into would allow me to be
> a little more proactive.
> 

Echoing Rekardo, I still check each commit as I git pull but I'm not
able to keep up with all of guix-devel, guix-help and bugs-guix anymore.
I currently have about 3000 unread emails in my combo
guix-devel/bugs-guix folder that I keep as a todo list of sorts of
patches to check or bugs to follow-up on. I feel overwhelmed by the
sheer number of emails and I feel guilty about not reviewing more
patches and bugs.

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

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

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Formalizing teams
  2021-12-28 18:03       ` Ricardo Wurmus
@ 2021-12-29 21:04         ` Lars-Dominik Braun
  0 siblings, 0 replies; 21+ messages in thread
From: Lars-Dominik Braun @ 2021-12-29 21:04 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel, Kyle Meyer, Maxim Cournoyer

Hi Ricardo,

> FWIW, mumi also lets you search patches as all contents are indexed:
>     https://issues.guix.gnu.org/search?query=%22%28gnu+packages+python-web%29%22+is%3Aopen+tag%3Apatch
thanks, I didn’t think about that. I tried searching
for python-build-system, but not all patches – especially
trivial ones – include enough context (for example
https://issues.guix.gnu.org/52595). Searching for files yields too many
packages, since Python packages are scattered across dozens of files
(e.g. gnu/packages/music.scm).

So unfortunately it doesn’t solve my problem. The only reasonable
thing to do right now seems to be setting up package name based filters,
because commit messages have a format known in advance.

Cheers,
Lars



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Formalizing teams
  2021-12-22 19:43 ` Filip Łajszczak
@ 2022-01-03 15:09   ` Ludovic Courtès
  0 siblings, 0 replies; 21+ messages in thread
From: Ludovic Courtès @ 2022-01-03 15:09 UTC (permalink / raw)
  To: Filip Łajszczak; +Cc: guix-devel

Hello,

Filip Łajszczak <filip@lajszczak.dev> skribis:

> Great idea. As a newcomer who created his first patch in May
> https://issues.guix.gnu.org/issue/48289/ that got a review, was fixed 
> and submitted again, and then disappeared into oblivion, I would be
> very happy to be able to ask some "Python packaging" team what is
> wrong with my patch. At the same time I'm grateful for everything that
> is being done all the time, so I'm not in a position to put any
> pressure on anyone. (BTW, I resubmitted it in the new style after The
> Big Change)

Oh, at least pinging people explicitly after some time has passed is
much welcome!  Hopefully someone will actually take a look this time…

Ludo’.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Formalizing teams
  2021-12-28 14:44   ` Ricardo Wurmus
  2021-12-29  9:05     ` Efraim Flashner
@ 2022-01-03 15:22     ` Ludovic Courtès
  2022-01-03 15:57       ` Ricardo Wurmus
                         ` (2 more replies)
  1 sibling, 3 replies; 21+ messages in thread
From: Ludovic Courtès @ 2022-01-03 15:22 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel, Maxim Cournoyer

Hi! ⛄

Ricardo Wurmus <rekado@elephly.net> skribis:

> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

[...]

>> We'd have to include every language/system of importance to that list
>> (Python, Ruby, Emacs, LaTeX, Perl, etc.), no?
>
> No, only those where we already have the people who could form a team.
> There is no need for any of this to be comprehensive.  It just needs to
> be an improvement over the status quo.

+1

> FWIW, I’ll gladly make it official that I could be the person to talk to
> when it comes to “R packaging”.  This is already the case, but only
> those people know it who don’t really need to know this.

Yes, and…

> Advertising this kind of information or recording it somewhere where our
> tools could redirect incoming requests would be an improvement.

… yes; see also “The Tyranny of Structurelessness”.  All this looks fine
to us insiders because we know the untold structure of group; to
outsiders though, it makes it harder to join.  It’s about making space
for newcomers.

> I do think it’s a lack of organization, yes.  Today I’m no longer
> following guix-commits, guix-patches, or bug-guix, and I’m overwhelmed
> by guix-devel and help-guix.  Whenever something catches my attention
> I’ll read a bit and maybe reply.  But by far the best way to get my
> attention for a review is to ask on #guix or #guix-hpc or to
> X-Debbugs-Cc (or Cc) me on emails.

I suppose people could explicitly Cc: the team you’re on when they need
specific advice or review; that should already help.

> Having some topic-specific streams I could tap into would allow me to be
> a little more proactive.

This brings a related but slightly different topic: how to let people
filter incoming patches and bug reports in general.

How does it even work on git*.com?  Do they let you subscribe to
issues/merge requests that match certain patterns or touch certain
files?

Thanks,
Ludo’.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Formalizing teams
  2022-01-03 15:22     ` Ludovic Courtès
@ 2022-01-03 15:57       ` Ricardo Wurmus
  2022-01-04 22:35       ` adriano
  2022-03-31 21:15       ` david larsson
  2 siblings, 0 replies; 21+ messages in thread
From: Ricardo Wurmus @ 2022-01-03 15:57 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel, Maxim Cournoyer


Ludovic Courtès <ludo@gnu.org> writes:

>> Having some topic-specific streams I could tap into would allow me to be
>> a little more proactive.
>
> This brings a related but slightly different topic: how to let people
> filter incoming patches and bug reports in general.

On issues.guix.gnu.org we could offer RSS/Atom feeds for items matching
certain queries.

-- 
Ricardo


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Formalizing teams
  2022-01-03 15:22     ` Ludovic Courtès
  2022-01-03 15:57       ` Ricardo Wurmus
@ 2022-01-04 22:35       ` adriano
  2022-03-31 21:15       ` david larsson
  2 siblings, 0 replies; 21+ messages in thread
From: adriano @ 2022-01-04 22:35 UTC (permalink / raw)
  To: guix-devel

Il giorno lun, 03/01/2022 alle 16.22 +0100, Ludovic Courtès ha scritto:


> This brings a related but slightly different topic: how to let people
> filter incoming patches and bug reports in general.
> 
> How does it even work on git*.com?  Do they let you subscribe to
> issues/merge requests that match certain patterns or touch certain
> files?

I don't remember exactly about Github and Gitlab

But I do remember about the Canonical issue tracking system for Ubuntu

When you file a bug there, you are asked to include a list of
packages/areas of the system you think your bug is about

That automatically informs the right people/teams

Also on Stackoverflow, you can accompany your question with some labels
(tags) and every tag is "followed" by some concerned people


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Formalizing teams
  2022-01-03 15:22     ` Ludovic Courtès
  2022-01-03 15:57       ` Ricardo Wurmus
  2022-01-04 22:35       ` adriano
@ 2022-03-31 21:15       ` david larsson
  2022-04-01  9:14         ` Ludovic Courtès
  2 siblings, 1 reply; 21+ messages in thread
From: david larsson @ 2022-03-31 21:15 UTC (permalink / raw)
  To: Ludovic Courtès
  Cc: Ricardo Wurmus, guix-devel, Maxim Cournoyer, Guix-devel

On 2022-01-03 16:22, Ludovic Courtès wrote:
> 
> I suppose people could explicitly Cc: the team you’re on when they need
> specific advice or review; that should already help.
> 
>> Having some topic-specific streams I could tap into would allow me to 
>> be
>> a little more proactive.
> 
> This brings a related but slightly different topic: how to let people
> filter incoming patches and bug reports in general.
> 
> How does it even work on git*.com?  Do they let you subscribe to
> issues/merge requests that match certain patterns or touch certain
> files?

github.com uses CODEOWNERS file which is well described here: 
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners#about-code-owners

Best regards,
David


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Formalizing teams
  2022-03-31 21:15       ` david larsson
@ 2022-04-01  9:14         ` Ludovic Courtès
  0 siblings, 0 replies; 21+ messages in thread
From: Ludovic Courtès @ 2022-04-01  9:14 UTC (permalink / raw)
  To: david larsson; +Cc: Ricardo Wurmus, guix-devel, Maxim Cournoyer, Guix-devel

Hi David,

david larsson <david.larsson@selfhosted.xyz> skribis:

> On 2022-01-03 16:22, Ludovic Courtès wrote:

[...]

>> This brings a related but slightly different topic: how to let
>> people
>> filter incoming patches and bug reports in general.
>> How does it even work on git*.com?  Do they let you subscribe to
>> issues/merge requests that match certain patterns or touch certain
>> files?
>
> github.com uses CODEOWNERS file which is well described here:
> https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners#about-code-owners

Yes, I like that approach; I suppose mumi could parse and honor such a
file with relatively little effort.  (I’d suggest “CODEFELLOWS” or a
similar name, but that’s another story. :-))

Ludo’.


^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2022-04-01  9:15 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-23 15:13 Formalizing teams Blake Shaw
2021-12-23 21:51 ` Jonathan McHugh
2021-12-24 12:23   ` Hartmut Goebel
2021-12-24 15:37     ` indieterminacy
  -- strict thread matches above, loose matches on Subject: below --
2021-12-22 15:46 Ludovic Courtès
2021-12-22 16:04 ` Jack Hill
2021-12-22 16:22   ` indieterminacy
2021-12-22 19:43 ` Filip Łajszczak
2022-01-03 15:09   ` Ludovic Courtès
2021-12-27  5:17 ` Maxim Cournoyer
2021-12-28 10:52   ` Lars-Dominik Braun
2021-12-28 15:44     ` Kyle Meyer
2021-12-28 18:03       ` Ricardo Wurmus
2021-12-29 21:04         ` Lars-Dominik Braun
2021-12-28 14:44   ` Ricardo Wurmus
2021-12-29  9:05     ` Efraim Flashner
2022-01-03 15:22     ` Ludovic Courtès
2022-01-03 15:57       ` Ricardo Wurmus
2022-01-04 22:35       ` adriano
2022-03-31 21:15       ` david larsson
2022-04-01  9:14         ` Ludovic Courtès

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).