| 1 |
On Sun, 7 Jun 2020 06:43:19 -0400 |
| 2 |
Rich Freeman <rich0@g.o> wrote: |
| 3 |
|
| 4 |
> Historically a lot of projects worked more like "tags" as an |
| 5 |
> alternative way of grouping packages other than categories. While |
| 6 |
> tags are a great idea projects are a terrible way to implement them. |
| 7 |
|
| 8 |
I was thinking perhaps instead of "group membership" oriented things, |
| 9 |
we could instead have a "developer proficiency" oriented system. |
| 10 |
|
| 11 |
Developers could choose skills from a defined list (like projects, but |
| 12 |
finely grained) |
| 13 |
|
| 14 |
Maybe with some WOT based proficiency rating thing. |
| 15 |
|
| 16 |
Then maybe the project system becomes used mostly for "primary |
| 17 |
ownership" of well maintained sets of things with great team structure, |
| 18 |
and the proficiency system becomes a defacto fallback for everything |
| 19 |
else. |
| 20 |
|
| 21 |
Packages are tagged with the sort of skills required to maintain them |
| 22 |
effectively, and people who have registered with said proficiencies get |
| 23 |
CC'd into the bug (somehow) and similar things. |
| 24 |
|
| 25 |
Like, for instance, when a package uses perl stuff, but isn't |
| 26 |
inherently owned by perl@, I still care, but registering that I care is |
| 27 |
tricky. |
| 28 |
|
| 29 |
And then potentially packages with above "good maintainer-ship" could |
| 30 |
indicate some sort of maintainer-ship grant to |
| 31 |
"people with proficiency > X in Y". |
| 32 |
|
| 33 |
Yes, I'm likely over-thinking everything here too much, but I suspect |
| 34 |
somebody could get some inspiration from something here :) |
Archives