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

[Jonathan Bryce]

Thanks for taking the time to respond! I appreciate your sharing your thoughts and experiences.

> On Mar 8, 2019, at 3:15 PM, Zach Reizner <zachr at google.com> wrote:
> 
> On Fri, Mar 8, 2019 at 12:05 PM Matt Wilson <msw at linux.com> wrote:
>> 
>> On Wed, Feb 20, 2019 at 02:25:56PM -0600, Jonathan Bryce wrote:
>>> Hi everyone,
>>> 
>>> On the rust-vmm community meeting this morning there was a
>>> discussion about the approval process for new crates. From the
>>> discussion a basic proposal emerged:
>> 
>> Hi Jonathan,
>> 
>> Thanks for writing this up, and for the infrastructure services from
>> OpenDev. I have some thoughts about this that I'd like to share after
>> a few disclosures:
>> 
>> 1) I am an Amazon employee, and Amazon is contributing to rust-vmm
>>   through the efforts of other employees. I have an interest in how
>>   the rust-vmm community grows in that context.
>> 2) I have not contributed code to rust-vmm, and I probably won't be
>>   able to participate in things like community calls due to my
>>   schedule.
>> 3) My thoughts about how to foster open source communities that
>>   I'm sharing today are my own, and do not represent the views of my
>>   employer. Therefore I'm wearing my individual hat and sending this
>>   from my msw at linux.com email address.
>> 
>>> - Create a group of rust-vmm project-wide maintainers
>>>      - Group size would start out with around 5 individuals
>>>      - Maintainers should come from a variety of backgrounds and
>>>        affiliations
>>>      - Inclusion of a new crate would require approval from at
>>>        least 3 maintainers
>>>      - Maintainers should look for approval and feedback from
>>>        multiple “consumer" communities (e.g. qemu, crosvm, kata,
>>>        firecracker)
>> 
>> I think it is much too early to establish this level of process about
>> governance, number of maintainers, approval process, etc. Before
>> establishing rules like this, I encourage communities to have a
>> transparent discussion about exactly what problems they (as a
>> community) are trying to solve. Due to my understanding of the
>> intended nature of rust-vmm crates, as building blocks that can be
>> used in other VMMs, this community may embrace a more decentralized
>> approach with smaller numbers of contributors, and healthy forking of
>> projects if the needs of a "downstream" are not met in the "upstream."
> 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.

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.

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.

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.

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.


>> There is no "one right way" to do open source. From past experience,
>> we know of many successful patterns, and many anti-patterns. I have
>> similar opinions about agile software development, and I encourage
>> teams to discuss what works the best for them, rather than prescribing
>> "you shall do agile development this way."
>> 
>> I have found the most accessible way to have these discussions is via
>> plain text email. Phone meetings and video conferences can be useful,
>> but there are challenges in scheduling due to timezones and competing
>> priorities. Additionally, they can exclude contributors that are
>> 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 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.


>> - As the number of crates scale, maintenance at the crate level
>>>  would be distributed beyond the project-wide group to avoid
>>>  overloading the project-wide maintainers or creating bottlenecks
>>>  within individual crates
>> 
>> I'm not sure what the overheads are here, having never done GitHub
>> organization management. Again, my suggestion is to get experience
>> with running the project before optimizing for a problem that might
>> not exist.
>> 
>>> I offered to write this up and post on the list to make sure
>>> everyone had a chance to see and comment on it, so please send your
>>> thoughts/feedback.
>>> 
>>> If this is agreeable as a process, we’ll need to bootstrap the
>>> initial set of maintainers. I have thoughts on that as well, but
>>> would love to hear others’ opinions too.
>> 
>> The idea that bootstrapping maintainers to reach a critical mass does
>> not sit well with me. I would like to encourage a much more organic
>> approach where natural leaders emerge based on their contributions
>> establishing the direction and shared technology of a project.
>> 
>> Finally, while things like logos are helpful promoting your project,
>> it's probably not the first order of business. Nor is it the first
>> order of business to obtain additional services from foundations. When
>> I was a board member of Software Freedom Conservancy (of which QEMU is
>> a member), and part of the Evaluation Committee considering
>> applications to join, we established the following as part of the key
>> criteria [1]:
>> 
>>   * The project should have an existing, vibrant, diverse community that
>>     develops and documents the software. For example, projects that
>>     have been under development for less than a year or only a "proof
>>     of concept" implementation are generally not eligible.

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.


>> Figure out who you are as a community, what problems you're trying to
>> solve, and how you want to interact with one another as
>> individuals. Creating a safe environment where people can collaborate
>> and earn trust of one another should be a high priority.
> I think this is a perfect take-away. A lot of us are just meeting each
> other for the first time and it will take time for us to build up
> trust with each other. That should be our first goal as a shared
> organization.
>> 
>> Make very intentional decisions here first. Experiment, double down on
>> what works, and re-evaluate when things don't. Discuss it intently on
>> a mailing list (... or don't, I do not have all of the answers here.)
>> 
>> --msw
>> 
>> [1] https://sfconservancy.org/projects/apply/


Thanks again for taking the time to chime in,

Joanthan