open source best practice due diligence

[clux]

General laundry list of things that I see CNCF wants (from their charter + project template & its github pages docs) filtered through some of my own thoughts and others (like from opensource.guide).

Still reading a bit on the implications on donating the project (had a break from thinking about this), but i think many things that are asked for are from CNCF are good things to have in a project anyway so listing out a few of them as I come across them.

NB: Closed the previous issue in #586 that was specific to donating to kubernetes or kubernetes-client org (i.e. no longer talking about merge/triage bots, stale-closers, or copyright headers), and I no longer think this is right for us.

• roadmap - https://github.com/orgs/kube-rs/projects/1/views/1 + pinned umbrella issues
• maintainers file (optional) - done in Maintainers + Governance + Security docs #671
• governance documents (not needed for sandbox afaikt - and once again linkerd has an easier alternative template) - done in Maintainers + Governance + Security docs #671
• security.md (simple linkerd variant) - done in Maintainers + Governance + Security docs #671
• guidelines for project contributors + code of conduct - done in cncf code of conduct #593
• issue templates and better contributing guidelines - add issue template + improve contributor help docs #699
• justifications for being donated and how we fit into the ecosystem (decent ones via donation of kube-rs to cncf #584)
• artwork finalization Refine our logo #570 - leaving this in the original issue - not necessary to do here, but would be nice.

Some other potential points (might re-raise these later to avoid this issue growing too much)

• ensure contributors are recognised better (mentioned in release info - communication)
• maybe invite people to help triage issues as a starting step to help contributing

Good background talks here:

• Turn Contributors into Maintainers with TAG Contributor Strategy.
• From Storming to Performing: Growing Your Project's Contributor Experience

[clux]

For a roadmap. I am experimenting a bit with the new github issues beta.

See https://github.com/orgs/kube-rs/projects/1/views/1 . It feels pretty decent, although might require some meta-issues here and there to describe some of the overarching goals.

Have made a tab for big goals and one for more incremental improvements. I have not gone through and categorised everything, just took a reasonable grab bag of some of the main things I saw in 5 minutes.

[kazk]

The new spreadsheet view looks nice! It's private, though.

[clux]

Have made it public for transparency but note to anyone reading this that the roadmap sheet is not yet an official thing
Edit: It's officially mentioned in repos elsewhere now.

[clux]

Have made a global .github repo in https://github.com/kube-rs/.github to house some of these policies and global files to avoid copy-pasting them around too much (by copy-pasting them initially..).

I plan to remove the maintainers, governance, code-of-conduct, and security file from kube-rs because github picks up on them if they are put in this special repo.

E.g. security policy + code of conduct show up on all repos now (check links hen creating new issue outside kube-rs)

Btw; the .github repos can be made to look quite nice: see github's, twitter's (link readme.md to see how repo is done). I've done it very plain so far. Feel free to help out here. Was thinking maybe to link to the core docs and where to get in touch.

[clux]

As for the roadmap; I am thinking of creating some umbrella stories for the big issues i've organised the roadmap around (primarily so that it makes a bit more sense):

• umbrella story for protogen (protobuf stories and main goal with the project)
• umbrella story for client-gold (subresources + protobuf + proxy + port-forward)
• umbrella story for process/documentation/donation/community (maybe process is the best common denominator of these terms - EDIT: no stability actually)

now there are probably other overarching goals that i have failed to pick up, that's glued together with the swath of incremental work (e.g. all the kube runtime improvements - hardest to set a clear big goal there i feel because all of us are kind of trying out various controllers in produciton and making incremental changes as appropriate). that said, if there are some way we can make big goals around kube-runtime or other big projects, we can add those.

• umbrella story for working rustls as a openssl replacement?
• umbrella story for 1.0 ? (versioning, policies, etc, but this kind of overlaps with process)

Anyway. Plan on doing this with an umbrella tag, and pinning them like in babel, and then close this issue in favour of more targeted process issues.

we could also use milestones for some of this stuff as well - but thinking that's best served on a per-release basis (so that we avoid creating an awkward "when do we do a release" problem) because you can't really write a lot of plans in a milestone.

(disclaimer: using a roadmap + umbrella issues / milestones here again is not to try to force a bunch of work on people, just to try to clarify what we want to accomplish, and writing about things tends to help that.)

[nightkr]

Makes sense to me.

[clux]

Ok, after much writing. There's two big umbrella stories pinned there. I realised they are a bit big and it's hard to keep track of edits there, but we can comment about things that are wrong, perform edits, and hide our comments about what we did as to keep them relatively noise free. Although, of course edit in issue links as appropriate without much ceremony.

Protobuf

#725 was relatively straight-forward to write, but there are probably many steps in the process towards production readiness that I have missed. Have done the best I could to interpolate between issues raised in various places, but comment on things that are missing, and open sub issues from things that do not have them.

Stability/Process

#726 was less straight-forward, but realised that most of what we had in there overlapped almost entirely with stability; all of it is there to make ourselves more presentable as a stable set of libraries with healthy governance and processes - so have re-categorised the process/donation/docs issues pertaining to this as "Stability", and written that umbrella story from that perspective. Do you think that narrative is right? If so, I'll close this issue and mark the roadmap situation as sufficient.

There might also be other things there also worth considering, but we can break out into exploratory issues rather than do everything on that issue.

[clux]

Other umbrella potentials. That I am leaving out for now, but think the last one here makes sense.

Gold

Left gold out for now because realised that it would basically just defer to the protobuf issue, because explicit gold requirements is merely: "Support exec, attach, port-forward calls" (which we do) + Proto encoding. so it would be a fairly pointless issue as an umbrella story.

Rustls

Might be worth writing a roadmap issue for rustls. People do keep running into issues (and everyone wants to use it as a default), most famously linkerd last (who now switched to openssl after trying for a while, but thankfully left it on rustls for embedded).

[kazk]

Do you think that narrative is right? If so, I'll close this issue and mark the roadmap situation as sufficient.

Makes sense to me. The objective is to establish kube as a trustworthy library.

[clux]

Cool 👍
Then I'll close this and defer to the big issue.