Trusteeship request / Policy for adding new trustees

[parsonsmatt]

Request 1: I'd like to be a Hackage Trustee. I'm doing a lot of work with dependency upgrades to new GHC versions, and many times it is mere restrictive upper bounds that prevent other libraries from easily building. I'd like to have Hackage Trustee power so I can revise these bounds.

Request 2: There doesn't appear to be an official policy for how trustees are evaluated, selected, removed, etc. Developing a policy for this may be a good step forward in providing transparency on the process and providing extra trust in what's going on.

[ulysses4ever]

Some prior art on Request 2: #336. Things a pretty dim, I agree (e.g. #336 (comment)).

[ulysses4ever]

Also related discussion on the Cafe: https://mail.haskell.org/pipermail/libraries/2020-June/030549.html

[andreasabel]

@ulysses4ever Thanks for the pointers!
As a start, I added a README on the hackage-trustee organization. But actually, this organization is irrelevant for the OP, relevant is the present repo: https://github.com/haskell-infra/hackage-trustees#readme. (I keep confusing these two resources, so maybe the README I added is just for me...)

[ulysses4ever]

@andreasabel than you! This new readme looks like a great first step. I hope that the readme in this repo could be extended to include more info (including answers to @parsonsmatt's questions) and explicitly say that you don't need to bother going elsewhere (e.g. Haskell wiki) to figure it out.

[ulysses4ever]

Couple ideas what could go to the readme here:

• a link to the have page with the list of Hackage trustees

• explicitly inviting to apply via this bug tracker (just like @parsonsmatt did)

[phadej]

I found that jack made revisions to serialise but doesn't seem to reported them upstream, not in well-typed/cborg#303 nor in well-typed/cborg#302.

This is nice but not nice:

maintainers should be notified via e-mail, by filing a bug tracker issue, or by sending pull request (in the future this step may be automated by hackage)

What worse, I have no idea who is jack and what their handle is on GitHub if any.

[endgame]

I object - those revisions were clearly documented in well-typed/cborg#303.

As a Hackage Trustee, I have made the following revisions:

* `cborg-0.2.8.0(vector)`: `>=0.10 && <0.13` -> `>=0.10 && <0.14`

* `cborg-json-0.2.5.0(vector)`: `>=0.10 && <0.13` -> `>=0.10 && <0.14`

* `cbor-tool-0.2.2.0(vector)`: `>=0.10 && <0.13` -> `>=0.10 && <0.14`

* `serialise-0.2.6.0(vector)`: `>=0.10 && <0.13` -> `>=0.10 && <0.14` (library, test suite `tests`, benchmark `instances`, benchmark `micro`, and benchmark `versus`)

[phadej]

@endgame sorry, I missed that completely. We really need a list with Hackage names - GitHub handles map.

[endgame]

Amen. I will try to remember to mention my Hackage handle when revising.

[andreabedini]

I am also interested in becoming a trustee (and happy to take advice on whether this is useful/a good idea).

[erikd]

I currently work with @andreabedini and previously worked with @parsonsmatt.

I am currently a trustee and I would approve of these two becoming trustees.

[jamesdbrock]

This is the list of current Hackage Trustees, right? https://hackage.haskell.org/packages/trustees/

There are 16 people in this group. I think this group is far too small, and the ideal size for the Hackage Trustees group would be like 50—100.

[phadej]

There was 750 distinct active uploaders on Hackage in 2022. 50 Trustees to look after them seems excessive.

Also uploads and revisions have been on the similar level for quite some time. Each major GHC release does create a spike in revisions, but I don't feel like the latency is huge.

In particular, I'm not sure it's good if trustees make relaxing revisions too quickly. That's what maintainers should do. If you (e.g. Andrea) feel that some package "sub-universes" need help in that, then I think the help will be better appreciated at the maintainers' end, compared to trustees make relaxing revisions.

As a maintainer myself, I'm actually quite annoyed by relaxing revisions made by others (as they break my ways of working, causing extra work), and I think that my reaction latency (on e..g GHC releases) is reasonable.

There are exceptions, like packages where trustees had made revisions for past N years of GHC releases. That's actually not great, and I don't think that having more trustees is the solution to those.

[andreabedini]

That's fair @phadej. Thank you for your input.

[gbaz]

Sorry for letting this languish for so long. I hoped we could get a policy first, then do more onboarding. Hopefully the HF can help in this regard (cc @david-christiansen) also cf #355

in the meantime, I'll reach out and start a discussion on the two volunteers in this thread, assuming they're still interested?