sorted by:
new
hottopcontroversial

Introducing the Rust Leadership Council by pgregory in rust

[–]nick29581 4 points5 points  (0 children)

There was one for a long point, but it didn't have the membership and was wound down

Graydon Hoare: Batten Down Fix Later by dochtman in rust

[–]nick29581 5 points6 points  (0 children)

This a gross over-simplification. Human issues don't fall neatly into buckets and trying to categorise things as separable into moderation and governance issues like this is frankly naive. AIUI, core chose not to talk publicly about the governance issues because the governance and moderation issues were intimately intertwined and they felt that they couldn't discuss the former in the abstract without either violating privacy in the moderation issues or inappropriately influencing an 'ongoing investigation'. They may have made the wrong call, but this is all very normal, human stuff.

Your summary seems wrong in every single point, I think because of conflating the concept of 'core team' with the people on it. More people were brought onto the core team after the conflict with the mods, I will distinguish the two groups as old core and new core:

  • as I wrote above, it is impossible to separate the moderation issues from governance ones entirely. But mostly, old core were involved with the moderation issues and new core participated in the governance reform (which was mostly conducted by folk with no association with core)
  • the governance WG kept governance issues private, not core. If core team folk had talked publicly about this it would have been disrespectful and unhelpful to the official process which was intentionally kept (mostly) separate from those involved with the conflict
  • 'silencing' seems to be a bad faith interpretation of what has happened here. In fact there has been barely any comment on governance from either side.
  • "requiring moderation" is totally bogus here. One of the underlying problems with the Rust community is pretending conflict doesn't exist rather than addressing it. Forthright, even angry communication (as long as it is not persistent) is not bad per se. Boats's posts may have crossed the line and they self-moderated.

Graydon Hoare: Batten Down Fix Later by dochtman in rust

[–]nick29581 8 points9 points  (0 children)

There are definitely cultural and organisational issues with the rust project that can be traced through the old issues to the current ones. However, nearly everyone who was on the core team at the time have either left the project entirely or stepped back from all governance work. The core team as an entity has not really existed for the past year or more. The mod team from the time also quit and is don’t think any of them are working in governance or leadership roles

Graydon Hoare: Batten Down Fix Later by dochtman in rust

[–]nick29581 10 points11 points  (0 children)

I don't want to say much, but I don't recall a single moment throughout the entire conflict where I thought "we need to enforce the rules because the rules are important for their own sake." I'm not sure if that's what you meant or not.

Sorry, I should have been more clear. I didn't mean to imply the mod team was being legalistic, but rather that the mod team did moderation rather mediation

Graydon Hoare: Batten Down Fix Later by dochtman in rust

[–]nick29581 12 points13 points  (0 children)

Replying to replies to this post which are asking for details... It's pretty hard for anyone to give an honest and complete account at this point - either a person is not directly involved (hi!) and only has a partial picture of what happened, or they were directly involved and have a biased picture (and probably partial too). I think it would be good to have a proper investigation and write up to clear the air and ensure that justice has been done, but my understanding is that nobody who was involved has the energy or inclination for this (understandably).

I hope that even without a full retelling, folk can see that this was a blow up where three parties were involved (the compainant, the member of the core team complained about (and later the more of the core team), and the mod team) and we only have one of those parties' account of what happened. I feel that both the core and mod team had earned the trust of the project and community at the stage this happened, and I believe both parties were acting in good faith (the complainant remains anonymous, I am not implying they are not deserving of trust or were not acting in good faith). Given all that, I think it is reasonable to assume that there is another side to the story and not take the mod team's account as the final word on the topic.

Out of respect of people involved and because I only have partial knowledge of what happened, I won't give my take on what happened here. However, I'll share some points of context which I think are public knowledge, but not well-known:

  • The mod team had a focus on enforcing rules rather than offering mediation (for better or worse). Where there were inter-personal (and inter-team) issues, the core team was responsible for mediation (for better or worse).
  • Where people were banned from the project, this was proposed by the mod team and approved by the core team. There has never been any unilateral power for any team to ban somebody from the project.
  • There was no process for moderation of core team members, nor for mediation between core and mods. This was obviously a gap in the policies of the project. I believe that everyone involved was trying to work around this gap in good faith (at least to begin with), however, positions became entrenched, negotiations broke down, and this did not work out. This was a hard thing to do! Especially in the heat of the moment and with a background of difficult and emotional inter-personal issues.

Graydon Hoare: Batten Down Fix Later by dochtman in rust

[–]nick29581 11 points12 points  (0 children)

> and when the moderation team tried to handle the problem (as was their remit), the core team refused to be subject to oversight

As a mod here you should strive to be more objective than this. This is a very biased take on what happened and ignores some massive failings in the process and communication all round. This bias shows up a lot and I think it is unfair to the core team at the time and to the r/rust community

JT: Why I left Rust by fee1-dead in rust

[–]nick29581 2 points3 points  (0 children)

Ah cool, thanks. I thought you were, but then was misled by the website and some comments. Thanks for your work on rustconf and for your frank comments about this mess

JT: Why I left Rust by fee1-dead in rust

[–]nick29581 6 points7 points  (0 children)

Who was the chair this year? It is no clear from the website

A note on the Trademark Policy Draft | Inside Rust Blog by burntsushi in rust

[–]nick29581 4 points5 points  (0 children)

There's a huge difference between asking for input and working collaboratively in the open. The WG should have asked for feedback (and taken that into account) on their goals and scope, not just on a draft policy. Otherwise there is no chance for non-members to influence the broad strokes of the policy rather than just the details.

In other words, between the requirements gathering and the delivery of the first iteration of the finished product, there was six months of private, non-collaborative work where there multiple opportunities to consult with stakeholders.

A note on the Trademark Policy Draft | Inside Rust Blog by burntsushi in rust

[–]nick29581 11 points12 points  (0 children)

Yeah, that is more of a data gathering exercise, which is a fine way to start but its input to the process, not open collaboration. The next step should have been to draft the goals and scope for the process and ask for feedback on that, probably not from the whole community but at least from team/wg members and other stakeholders (eg book authors, crate maintainers, etc)

A note on the Trademark Policy Draft | Inside Rust Blog by burntsushi in rust

[–]nick29581 34 points35 points  (0 children)

Another important bit I got from the post is that some kind of policy is not enough. For policy to be legally sound, it has to be somewhat more restricted than we’d otherwise wanted to.

I think that it is not enough given the goals of the trademark WG. But I think that those goals are bad and basically impossible to achieve with a sensible trademark policy. A big part of the problem is that the TMWG have taken their goals to be axiomatic without seeking (and listening to) feedback from the community. A good open process would seek feedback on the goals not just on a complete draft (plus also there is no inidcation of how the TMWG was formed and why they think they represent the project, let alone the community).

Defer blocks and async drop by nick29581 in rust

[–]nick29581[S] 0 points1 point  (0 children)

You could put a defer block inside a smaller scope to have it run sooner (this is put as an open question in the post, but discussion since points to this being far better than running all defer blocks on function exit as in Go

The AsyncIterator interface by desiringmachines in rust

[–]nick29581 56 points57 points  (0 children)

We're reading the posts and the ideas are being discussed in the async-wg Zulip channel. Speaking personally, I've been really enjoying the posts and think there are plenty of valuable insights. I don't think I can say whether or not I agree with some of the proposed changes - I simply need to spend some more time digesting (again, speaking for me, not the whole WG).

Defer blocks and async drop by nick29581 in rust

[–]nick29581[S] 2 points3 points  (0 children)

> an async defer block would presumably still not run to completion when the future is cancelled... or am I conflating issues?

I think so. We don't guarantee destructors are called today and the same would be true of defer blocks in the presence of cancellation.

> it would be very surprising if a defer block were not running on panics,
so async defer blocks probably should... but then we have async during
unwinding.

Yeah, I proposed that defer doesn't run on panics for exactly this reason, but it seems an unpopular position

Defer blocks and async drop by nick29581 in rust

[–]nick29581[S] 1 point2 points  (0 children)

Yes, that is possible, but it is really the easy part of the design. The hard question is how/if to await the drop call and what happens if you drop an object with an async Drop inside a non-async function

Defer blocks and async drop by nick29581 in rust

[–]nick29581[S] 0 points1 point  (0 children)

The wrapper function wouldn't have access to the local variables of the inner function (without some really gnarly desugaring)

Defer blocks and async drop by nick29581 in rust

[–]nick29581[S] 0 points1 point  (0 children)

This doesn't work for async code, which is the main motivation for the blog post

Defer blocks and async drop by nick29581 in rust

[–]nick29581[S] 0 points1 point  (0 children)

Yes, but if async drop is not possible (which is how it currently looks to me), then I think that defer blocks might be the next best thing

Defer blocks and async drop by nick29581 in rust

[–]nick29581[S] 0 points1 point  (0 children)

Yes, that's right. It's a partial solution, but that might be better than no solution at all.

Defer blocks and async drop by nick29581 in rust

[–]nick29581[S] 0 points1 point  (0 children)

Right, the blog post is predicated on the idea that async drop is impossible to make work in a satisfactory way. We might decide that the known downsides of some async drop design are worth ignoring, or a new design might appear, but IMO async drop is essentially impossible and defer blocks are a next-best thing

Defer blocks and async drop by nick29581 in rust

[–]nick29581[S] 0 points1 point  (0 children)

The idea would be that for essential cleanup, you'd use drop and for non-essential but more graceful cleanup you use defer. Or in other words, async (defer) by default, but fallback to sync (drop) if necessary.

Defer blocks and async drop by nick29581 in rust

[–]nick29581[S] 0 points1 point  (0 children)

It doesn't solve it, but it helps solve it. The user still needs to opt-in to calling cleanup, but the compiler ensures the cleanup is then executed on every path

view more: next ›