1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
|
How to make a scaleable package registry?
* Require moderation/review of everything? It's nicer, because the won't be
a need to act quickly (e.g. to remove malware).
- But allow updates to be downloaded, if explicitly requested,
even if they haven't been reviewed yet.
* Have a system with "review points"?
- Each package needs to reach a certain threshold of "review points"
before being considered to be reviewed.
- New packages need to reach the threshold before becoming visible?
And also updates from new users? And API changes?
- API and implementation could be reviewed separately.
The implementation is easier to change, so it could be reviewed
with a lower threshold.
- The threshold could very between sections, e.g. security or network
related packages. This could partly be detected automatically by
checking which dependencies are used.
- Different reviewers could have focus areas, where they have more
review points. Some areas could require a certain number of reviews
from a specific group of reviewers.
* Have a semi-automated flagging system
- Require more review points if an upload/version/package gets flagged,
otherwise it gets hidden.
- Notify moderators (but don't hide) packages that are widely
used and have existed for some time (e.g. a month).
* Special "trusted moderators" could have more powers to hide/delete or
unhide things.
* Strongly encourage (or even require) team-based package management.
- But allow pre-review with veto rights for stable APIs/interfaces,
which are impossible to change. E.g. a specific user/group has to
review API changes, and only if no answer (or accepted) the interface
change is published.
- There could be many different sub-teams, depending on skill-set of the
members. A user could belong to many teams.
- Review could be required from multiple teams (e.g. "network team",
"accessibility team" and "API team").
- There should be some way for a board of some association to remove
a person from a team (or even suspend the persons account).
- Teams could have both "members" and "package moderators".
Members could them be able to elect package moderators.
* Perhaps have "upload sections", where each section is handled by an
"association-team". The association-team would have members, a board,
and bylaws (with some instance-wide requirements), and would hence
(in the jurisdiction of Sweden) legally be an association on its own.
- There could be a "std" section for standard things.
- There could be a "edge" section for non-standard or unfinished things.
- External associations/projects could have their own section.
(Should there be a difference between internal and external projects
even?)
- Non-associations could be allowed on a case-by-case basis,
if they are doing a public good, have reasonable values,
are reasonably democratic/open, etc.
(For example non-profit F/OSS foundations, as long as they
have reasonable values)
|
