Re: Formalizing teams

Re: Formalizing teams

[Blake Shaw]

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”

Re: Formalizing teams

[Jonathan McHugh]

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

Re: Formalizing teams

[Hartmut Goebel]

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 |

Re: Formalizing teams

[indieterminacy]

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.

Formalizing teams

[Ludovic Courtès]

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’.

Re: Formalizing teams

[Jack Hill]

[-- 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

Re: Formalizing teams

[indieterminacy]

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

Re: Formalizing teams

[Filip Łajszczak]

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

Re: Formalizing teams

[Ludovic Courtès]

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’.

Re: Formalizing teams

[Maxim Cournoyer]

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

Re: Formalizing teams

[Lars-Dominik Braun]

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

Re: Formalizing teams

[Kyle Meyer]

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/>.

Re: Formalizing teams

[Ricardo Wurmus]

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

Re: Formalizing teams

[Lars-Dominik Braun]

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

Re: Formalizing teams

[Ricardo Wurmus]

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

Re: Formalizing teams

[Efraim Flashner]

[-- 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 --]

Re: Formalizing teams

[Ludovic Courtès]

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’.

Re: Formalizing teams

[Ricardo Wurmus]

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

Re: Formalizing teams

[adriano]

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

Re: Formalizing teams

[david larsson]

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

Re: Formalizing teams

[Ludovic Courtès]

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’.