Add an amendment to the RFC process #9
Conversation
|
This all sounds great to me and I think addresses some pain points we've been hitting over the past months. Thanks for writing this up @fitzgen! |
|
so, I have a few comments on this RFC. Firstly, I think in general that a lot of this issue could be solved by more practical personal communication between the core team members, including but not limited to pings on Discord/IRC/Twitter/phonecalls. It is clear to me that this RFC was filed due to my absence (just to call out the elephant in the room). I think that it's quite fair in calling that out, but I am vaguely frustrated that I wasn't personally contacted by other members of the core team before it was filed. Despite having a very limited amount of time over the last few months (due to shipping the 2018 edition website, losing my contract at Mozilla, interviewing for new jobs, and moving across the country), if given a personal ping that stated that I was really holding things up, I would have made the time. I even personally reached out to the other members of the core team via email to note that a lot of RFCs were hitting FCP at a time that was very difficult for me (and setting a personal goal to accomplish them that I'll admit I failed). The responses I received were positive and encouraging. There were no emails following up on that thread letting me know that things were becoming a problem that would warrant a change to the RFC process. I'd like to think we are a small team of folks who are friendly with each other, who can opt to handle things personally before feeling the need to legislate further process. There's also an interesting statement in this RFC:
I'm not entirely sure this is something we have consensus on. I don't necessarily think that we should specifically move slowly, but I do think that the Rust project has generally rejected the "Worse is Better" idea, in favor of more time spent in the design process. I agree that the Wasm space is young, but the question around how quickly things are moving could probably benefit from some exploration. Additionally, I think there are some fundamental disagreements on how quickly we should be moving- for example, when I choose to make a wasm-pack release I spend a lot of time and effort to make sure that the release is valid and working well, whereas we've seen a bit less diligence on the wasm-bindgen side. This is not meant as a denigration of that project's release strategy, rather, I think these are both valid strategies, and so think we should hesitate to canonicalize a "move fast" value for the whole working group universally. Lastly, I think we should be aware of the core team's current composition. Alex and Nick both have full time jobs at Mozilla. In an effort to keep this project a truly vendor agnostic open source group, I think we should be wary of processes that could lead to a single vendor being able to push through decisions on a timeline that may not be inclusive to others. I don't personally think that the timelines here are necessarily too aggressive, but I think we should be open and honest about keeping the project legislated in a way that people who do not work on this as a full time job can participate (and even lead) if they so choose. I look forward to discussing this further in the meeting. |
I agree that we need to add more core team members, particularly folks who aren't employed by Mozilla. This RFC amendment takes great care to ensure that it does not allow pushing decisions through the RFC process without others' consideration. It does not make the FCP proposal into a vote where a majority can ram an RFC through even if a minority disagree. If a team member has concerns about an RFC, all they need to do is comment in the thread and bring up the concern, and the FCP proposal is blocked until the concern is resolved. Or dropping a quick note about being unavailable for X period of time, and will respond by Y date, so that the other members know what's up. All that is required is engaging in the RFC thread and communicating with the other team members. This RFC amendment only aims to handle the situation where a team member is not engaging in RFC threads or communicating with other team members due to unforeseen life events. To be clear, there are any number of valid reasons for a team member being unavailable! But one team member being unavailable must not halt all RFC progress indefinitely. Finally, as we add more core team members, the probability that any one member is unavailable at a given time approaches 100%, which means that we need this RFC amendment even more as we bring new team members in.
I feel this is an unfair characterization of the situation. We have been reaching out to you in RFC threads — multiple times — and we don't receive any response from you. 0 1 2 3 4 5 However, I am going to leave it at that, because I'd like to avoid getting into the weeds of particular past events, because I believe this RFC process amendment is something we want regardless. |
These two points seem opposed to eachother: if it is expected that team members should share a close personal relationship (e-mail, phone calls, etc.) rather than discussing things publically, that is very hostile toward outside inclusion. So I'm against the idea of treating team members like an exclusive club of friends. Things should be discussed publically, not in private e-mails or phone calls. I think Rust already has too much private discussions. I think giving pings on the actual RFC itself is the most reasonable course of action, rather than relying on third-party sources of communication. I think it's reasonable to expect team members to have e-mail notifications (or similar) turned on for the RFC repo, since it is so important. I'd also like to note that the It's nothing personal, and nobody is blaming anybody else. People get held up all the time, for a wide variety of reasons! So the RFC process should be accommodating toward that, rather than grinding to a halt and generating passive frustration toward the inactive member. |
|
I don't really have much more to add over what @fitzgen and @Pauan already said myself. The main takeaway I have from this RFC is that this is something we're always going to want, even if @ashleygwilliams had been active the past 6 months. While motivated by your absence @ashleygwilliams this is a realization of something that we'll always want to have. I think we all understand that life gets in the way sometimes, and if a team member has higher priorities than the working group for an extended period of time we all think that's totally ok. The main point here is that when this happens the project shouldn't come to a standstill until all team members can refocus on the working group, but rather we should have a reasonable process in place for continuing the working group at an adequate pace. |
|
@ashleygwilliams have you had a chance to review the comments above? |
|
After having some good heart-to-heart with @alexcrichton and @fitzgen about our interpersonal interactions, I feel much more comfortable about this RFC. I would be prepared to approve this, with one consideration. I'd like to remove "There is a fundamental trade off between shipping and team member availability at play. Because of how young the Wasm space is, and how quickly it moves, we are inclined to err towards the shipping side of this trade off." I don't think I fully agree with it, but I also don't think the RFC requires it, so the time spent collaboratively wordsmithing it is probably better used elsewhere. If we remove it, I'd move for FCP. |
|
I'm proposing that this RFC enter its final comment period with disposition to merge. @rustwasm/core team members to sign off: |
|
I thought of something... rather than using a custom ad-hoc system where team members have to check a box... why not use GitHub's already existing review system? I believe we can set it up so that all RFC PRs would require 3 reviewers to approve (i.e. how many team members there are), and then team members can approve the PR, request changes, or reject the PR. A great example is this RFC, where at the bottom it clearly shows that @alexcrichton has approved the changes, but @ashleygwilliams has requested changes. Since it's using GitHub's official system, we get notifications when a team member approves the PR, unlike right now where we don't. |
|
That seems like a cool idea! I don't think we need to block this amendment on it, since it seems orthogonal. |
|
i agree that @Pauan's idea is cool- but an impl idea we shouldn't block this on! maybe we can add a tracking issue in the team repo for exploring that more? |
|
🔔 🔔 🔔 This RFC has entered its final comment period. In seven calendar days, assuming no substantial new arguments or ideas are raised, we will merge it. |
|
Oh, yeah, totally, I didn't intend it to block this PR, it was just a thought I had. |
Rendered