Governance updates?

[djc]

cc @worldwise001. Going to set the stage with some context:

• rustls-platform-verifier was originally created within 1Password. It was open sourced and transitioned to live with in the rustls GitHub org (judging from PR history, looks like that happened near the end of 2022).
• @complexspaces has been the primary maintainer both inside (as far as we know) and outside 1Password. As a result, the (perceived?) ownership situation has been that @complexspaces needs to sign off on ~all PRs before they get merged.

@cpu in #119 (comment):

From my perspective the norms for reviewing those PRs hasn't been set in this repo, or written down explicitly. I personally don't feel enough ownership here to blanket +1 updates that don't affect MSRV like I might in rustls/rustls or rustls/webpki.

I remember @complexspaces pushing back on landing the automation and in retrospect I think it would have been better to work through some kind of policy/expectation-setting before landing the automation. Lesson learned :-)

@complexspaces in #119 (comment):

I hope no one feels bad about the current state of the lockfile/dependency updates, that wasn't my intention at all. I tend to not look at the PRs because my OSS time is already fairly limited.

I did push back when first proposed because it seemed weird to me to update dependencies via lockfile just because they had updated, since this is generally not what I do at work or personal projects. I tend to only do dependency upgrades when there's a new direct dependency and then make sure the lockfile is clean as an end result.

For the rustls project, currently @ctz is full-time, @cpu is about half time and I spend quite a bit of time as a volunteer. As such, we have a decent amount of bandwidth for small updates/improvements/maintenance. From what I've observed, @complexspaces often doesn't feel like they have enough bandwidth at work to spend on rustls-platform-verifier, and so their work on rustls-platform-verifier sometimes becomes intermittent (for example, there recently was a bunch of work from their vacation). On the flipside, because the rustls maintainers want to respect the donation of rustls-platform-verifier from 1Password to our project and don't want to cause problems for your internal usage of the project, we are hesitant to make changes without explicit approval from 1Password staff (that is, @complexspaces).

Which led me to this question in #120 (comment):

A potential third topic for discussion: being more explicit about ownership. So far I think we've mostly deferred to @complexspaces on any half-way nuanced changes, but the downside is that @complexspaces has pretty limited bandwidth certainly compared to the other rustls org maintainers. Maybe we can get to a tweaked proposed governance model?

To make this concrete, I think as rustls maintainers it would be nice if we could take a little more ownership of the project, where we would not block merging on PRs without 1Password/@complexspaces approval at least where we feel we have enough expertise (which might be limited for some of the platforms).

(As rustls maintainers, we would also like rustls-platform-verifier to be more broadly used, since it seems like a better/more secure alternative to basic rustls-native-certs -- unfortunately there are still some rough edges here and potential further improvements especially on platforms that don't really have a platform verifier.)

What do people think? (Please feel free to correct me if I've gotten something wrong.)

[cpu]

I'm back from vacation and would be interested in moving this discussion forward. I think djc has done a good job of capturing the state of things (thanks!). I'd like to hear from the 1password folks before weighing in with any further thoughts of my own.

[djc]

@worldwise001 any thoughts? Would be nice to make some progress here.

[djc]

@worldwise001 friendly ping?

[cpu]

@complexspaces is there a way you can help get this discussion moving? It's been ~2.5 months since the comment that invited us to split off a separate issue.

[complexspaces]

Hi, sorry, this one has actually been waiting on me to reply or say something. I've been having a hard time thinking of what to write since the subject has slightly unpleasant to think about (and I've had a lot going on). In the meantime my brain has been trying to stay more active in this repository instead to see if I could keep up in a healthier way.

looks like that happened near the end of 2022

That's correct 👍. At the time I thought it was more feature complete, which ended up not being true (thankfully) but it was at a point of stagnation internally because it fit all of our internal needs. I wanted to open source it because it would be way better as a tool for the community. Part of my original expectation about the maintenance work required was, put lightly, wrong and a bit of a shock. This is not a bad thing, though.

@complexspaces has been the primary maintainer both inside (as far as we know) and outside 1Password. As a result, the (perceived?) ownership situation has been that @complexspaces needs to sign off on ~all PRs before they get merged.

The first point here is correct. Inside 1P I've been the primary contributor for some time, with a little bit of assistance here and there. However, there hasn't been an ownership perception like you described. No one internally at the company is expecting that of me. The desire to review and "see" all of the incoming stuff is to make sure nothing breaks hard in our repositories that use rustls-platform-verifier because it'd (probably) be harder to fix later and to keep a current understanding of the codebase.

On the flipside, because the rustls maintainers want to respect the donation of rustls-platform-verifier from 1Password to our project and don't want to cause problems for your internal usage of the project, we are hesitant to make changes without explicit approval from 1Password staff

I appreciate this, thank you. However we did make the choice to open source it 2 years ago and ideally genuine improvements should not be held back by 1P's requirements, especially since priorities and status don't align all the time. That's just part of "donating." I want this crate to be good for the Rust ecosystem.

To the primary point though:

To make this concrete, I think as rustls maintainers it would be nice if we could take a little more ownership of the project, where we would not block merging on PRs without 1Password/@complexspaces approval at least where we feel we have enough expertise (which might be limited for some of the platforms).

Long story short: I don't think that I have any problem with this. It'd probably be helpful for me to learn more flexibility to collaborate on shared projects as well. A huge amount of this has boiled down to my comfort: I have almost no experience sharing large projects and that leads me to try and keep everything within what I know, despite that causing conflict at times (ex, the dependabot lockfile stuff). I really hope this tendency hasn't caused any hurtfulness.

To provide more background: I have a pretty nasty fear of bugs/regressions/imperfections occurring because of some personal headspace limitations. I expect that has been coming across in the wrong way (long delays while I look for other options, etc). Secondly, I've done a lot of digging/reading/reversing of the various platform's TLS stacks and I want to make sure that can be utilized for the project's success while continuing to learn more myself.

Relatedly, I get concerned/anxious when the other maintainers say a lot around the lines of "I don't know $PLATFORM very well, but on the surface it looks fine" during PR review, further exacerbating the fear I mentioned earlier. I don't blame anyone for this though, to be clear. I just haven't thought of a (personally) comfortable middle ground at this time.

With all of that said, in the end, I'm happy to try and work out a more feasible maintenance schedule and distribution with the other maintainers here and see what the rustls org-side thinks would be reasonable.

[djc]

Thanks for candidly describing your experience with sharing ownership of the project so far!

Hi, sorry, this one has actually been waiting on me to reply or say something. I've been having a hard time thinking of what to write since the subject has slightly unpleasant to think about (and I've had a lot going on).

I'd be curious to understand why it is unpleasant for you, mainly with the goal of understanding if there are things I/we could do to make it less unpleasant.

In the meantime my brain has been trying to stay more active in this repository instead to see if I could keep up in a healthier way.

I think getting the unpleasant stuff out of the way might be long-term healthier. 🙂 But, either way, all of your efforts are much appreciated!

looks like that happened near the end of 2022

That's correct 👍. At the time I thought it was more feature complete, which ended up not being true (thankfully) but it was at a point of stagnation internally because it fit all of our internal needs. I wanted to open source it because it would be way better as a tool for the community. Part of my original expectation about the maintenance work required was, put lightly, wrong and a bit of a shock. This is not a bad thing, though.

You're not quite coming out and saying it, but I think you're suggesting that the maintenance has involved a lot more work than you expected? I can see how that might be true. I also feel like, once we get the next release out, the remaining work should be relatively smooth sailing because we've ironed out most of the issues. But hard to speculate on unknown unknowns...

To the primary point though:

To make this concrete, I think as rustls maintainers it would be nice if we could take a little more ownership of the project, where we would not block merging on PRs without 1Password/@complexspaces approval at least where we feel we have enough expertise (which might be limited for some of the platforms).

Long story short: I don't think that I have any problem with this. It'd probably be helpful for me to learn more flexibility to collaborate on shared projects as well. A huge amount of this has boiled down to my comfort: I have almost no experience sharing large projects and that leads me to try and keep everything within what I know, despite that causing conflict at times (ex, the dependabot lockfile stuff). I really hope this tendency hasn't caused any hurtfulness.

To provide more background: I have a pretty nasty fear of bugs/regressions/imperfections occurring because of some personal headspace limitations. I expect that has been coming across in the wrong way (long delays while I look for other options, etc). Secondly, I've done a lot of digging/reading/reversing of the various platform's TLS stacks and I want to make sure that can be utilized for the project's success while continuing to learn more myself.

Relatedly, I get concerned/anxious when the other maintainers say a lot around the lines of "I don't know $PLATFORM very well, but on the surface it looks fine" during PR review, further exacerbating the fear I mentioned earlier. I don't blame anyone for this though, to be clear. I just haven't thought of a (personally) comfortable middle ground at this time.

With all of that said, in the end, I'm happy to try and work out a more feasible maintenance schedule and distribution with the other maintainers here and see what the rustls org-side thinks would be reasonable.

I would suggest the following: for PRs that do not touch the low-level platform-specific verifier parts, we stop blocking on your reviews and follow our usual policy of having 1 or 2 maintainer reviews depending on the risk involved (like, test-only or documentation changes might not need 2 reviews). For PRs that touch the hairy parts, I'd be happy to keep PRs open longer so we can benefit from your experience.

For the latter cases, I think what could help substantially is if you could articulate any concerns or research topics you have in an issue/PR, instead of triggering "long delays" while you look for other options/do more digging/reading etc. That way (1) other maintainers can more directly benefit from your experience and (2) we can find ways to spread the load of assessing/mitigating risks together.

[cpu]

I don't think I have much to add here. Djc's thoughts seem in line with mine and it doesn't feel like there's much of a gap between where everyone is at.

Thanks for writing down your perspective 🙇

For the latter cases, I think what could help substantially is if you could articulate any concerns or research topics you have in an issue/PR, instead of triggering "long delays" while you look for other options/do more digging/reading etc.

+1 - it's hard to interpret what's going on where there's radio silence. I think it's natural & expected for some things to be harder to review confidently, or for some issues to require more time to ponder the right response. Capturing that early with a short comment is helpful and hopefully not too much of a burden.