[Rust-VMM] Proposal for contribution and crate approval process

[Matt Wilson]

On Fri, Mar 15, 2019 at 05:23:08PM -0500, Jonathan Bryce wrote:
> Thanks for taking the time to respond! I appreciate your sharing
> your thoughts and experiences.

My pleasure! Thank you for supporting this emerging community. :-)

> > On Mar 8, 2019, at 3:15 PM, Zach Reizner <zachr at google.com> wrote:

[...]

> > I agree with your statement about it being too early to establish such
> > a high-level of governance. What you said about forking and
> > decentralized approaches certainly matches my observations so far.
> > From my perspective, a decentralized fork (firecracker from crosvm) is
> > part of how this organization got started. I don't see any signs of
> > that stopping, as crosvm is starting to incorporate and modify
> > vhost-user pieces posted here in order to adapt it to our code base.
> 
> Thanks for the feedback on the proposal. I have zero attachment to
> these ideas and was primarily putting them on the mailing list so
> the widest possible audience would have a chance to review and
> comment. So feel free to beat up on them as much as possible.

Yup! I didn't take your conveying the notes from the call to mean they
were your ideas.

> I agree that too much governance too early in a project is bad. I
> tend to think of governance in its simplest form as an agreed upon
> (and ideally documented) method for making group decisions. While I
> don’t think there’s a need for heavyweight governance processes here
> right now, here’s the quick background on how this proposal came
> about. This additional context probably would have been good for me
> to include the first time around, so thanks for pushing on that,
> Matt.
>
> Andreea had previously put forward a basic process for creating
> crates in the organization. As several initial crates were proposed,
> people asked how much and what kind of review should be required
> before a crate should be considered accepted and included as part of
> the overall project. This was the specific item where there wasn’t
> yet an agreed upon method for making the group decision.

Got it. I think we need to provide some guidance on when process is
important. Processes sometimes become a proxy for the thing that
you're really after. Let's say it's quality: you may adopt a process
that includes some steps between doing development and testing, and a
process for turning bugs into test cases. If you're not careful, the
process can become the thing everyone focuses their attention on, and
the outcomes are lost.

When considering this question, "what kind of review should be
required before a create should be considered accepted [...]?" first I
would want to understand what are the downsides to accepting any new
crate that is aligned to the overall charter of the project? Is this a
one way door? Does it take a lot of resources from the members of the
project to accept a new crate? Why not allow new crates to be
developed outside of the community, and "graduate" them in?

> Someone added this topic to the agenda for the call a few weeks
> back, and the people who were on wanted some way to review a crate
> before it was added as a repo, get input from multiple different
> stakeholders (e.g. crosvm & firecracker devs), and have something
> documented so that there would be agreement when a crate should be
> added and new contributors could have the correct expectations set
> if they were going to propose a new component.

Being a Rust novice, I don't know if the concern here is namespace
management, or something else.

> After chatting about it, it seemed like people had generally arrived
> at the above proposal, and I volunteered to put it on the mailing
> list so those who weren’t on the call could weigh in.

And thank you for doing so! :-)

> Earlier in this thread someone had proposed a more unified
> architecture across crates which seemed like something that most
> people agreed we didn’t want. That was abandoned by the poster. On
> the above component addition proposal, I think it would be good to
> hear either specific changes or maybe some alternate ideas from the
> people who are actively working through existing crate proposals if
> we’d like to make some changes. I do think it’s useful to have
> something documented to set expectation for potential contributors,
> even if it’s lightweight.

I think it would be good to talk about some design tenets or
principles. Rather than documenting the governance / process, first
set down what problems you're trying to solve, and general thinking
about how the group might want to solve them. It may be that a highly
decentralized and a "please feel free to fork" mentality will be more
aligned with the problems that are being tackled by the individuals
here.

> >> There is no "one right way" to do open source. From past experience,
[...]
> >> unable to participate in speech based conversations. I encourage this
> >> emerging community to find what works well for the individuals who are
> >> showing up to collaborate, but be aware of who you may be
> >> unconsciously excluding.
> >
> > I also agree with that. The phone calls are somewhat earlier than my
> > ordinary sleep schedule, which means I've only got to 2 of the last 3.
> > The only other crosvm representative has only been to the first phone
> > call.
>
> Thanks for bringing up this point too, Matt. I’ve worked in
> communities with extremely diverse and global participants, and I
> agree with you that I have seen email as the most inclusive and
> reliable way to discuss and hash out topics. At the same time, I
> think that high-bandwidth collaboration opportunities can be super
> valuable, especially in early days as people are getting to know
> each other and building trust when individuals may hesitate to ship
> their ideas off to a public mailing list. One technique that I have
> seen help is to bring the ideas from the real-time discussions to an
> asynchronous medium as proposals and then allow people ample time to
> digest and share their opinions.

I agree with all of this as well.

> I think that some people are comfortable using GitHub as the
> asynchronous medium, even though I may personally have an attachment
> to traditional mailing lists. But then, I also like IRC…call me old
> fashioned—or just old. I think it’s good to have an intentional
> discussion about where to drive these conversations, though.

I, too, have an affinity to traditional mailing list and IRC over
GitHub and Slack. :-) I support having an intentional discussion, and
ultimately the folks who will be having those conversations more
regularly than I will chime in will figure it out.

[...]
> But logos are fun! = ) In all seriousness, I think logos are a
> fairly lightweight item that helps give a team of people that are
> distributed across countries and companies a sense of shared
> identity.

It's true, logos are fun. I'm mainly making a fuss to highlight the
importance of the other things.

[...]
> 
> Thanks again for taking the time to chime in,

My pleasure, and thanks again for your support.

--msw