>jeu. 05 févr. 2026 at 11:57, Nguyễn Gia Phong <[email protected]> wrote:
> On 2026-02-04 at 15:02+01:00, Cayetano Santos wrote: >> mer. 04 févr. 2026 at 11:03, Nguyễn Gia Phong wrote: >> > Relevant to my $dayjob (research on software engineering) and interests, >> > I want to create a team taking care of the following packages modules >> > (with overlapping teams): >> > >> > - auto*, build-tools >> > - benchmark >> > - bison, oyacc, maybe merged as yacc, and re2c >> > - check and *-check (*) >> > - code >> > - ci (core) and task-runner (sysadmin), >> > see also https://codeberg.org/guix/guix/issues/3096 for merging them >> > - coq (ocaml), lean (science) and logic stuff in maths (science) >> > - debug and libunwind >> > - hexedit, text-editors and tree-sitter (emacs) >> >> To me, the idea of teams is building a group of people interested on a >> common subject. The previous list being somehow orthogonal to different >> topics, it is going to be difficult to motivate some other people to >> join such a team based on one’s personal interests. > > Fair enough, how about it reduced to the following. > > Build tools: > > - auto*, build-tools > - bison, oyacc, maybe merged as yacc, and re2c > > Quality assurance: > > - benchmark > - check and *-check (*) > - code > - ci (core) and task-runner (sysadmin), > - debug and libunwind > > I just at least want to have fewer modules team-orphaned. Teams are positive (we have more than 50 at this point !), and avoiding orphaned packages is a nice initiative. Feel free to propose a pr with a coherent list of modules, including yourself in the corresponding team. Just remember that a single person team has little utility, and you’ll have to gather extra manpower around the team, which will strongly depend on its interest for a larger community. C.
signature.asc
Description: PGP signature
