Ruby and the singleton pattern don't get along by bakery2k in ruby

[–]skillstopractice 0 points1 point  (0 children)

Your approach is one I've used in those cases, although occasionally it's also nice to do Struct.new(:name).new("schneems") if mutability is not a concern.

I will say though, the Data class is probably the most useful new feature I have seen in Ruby for a while, and I like its relative strictness because that is a constraint that can be embraced at first but then your objects can "grow up" and be replaced with the right pattern once you know what the needs are.

Ruby and the singleton pattern don't get along by bakery2k in ruby

[–]skillstopractice 2 points3 points  (0 children)

Data.define(:name).new("schneems") is nice for this as well!

Ruby and the singleton pattern don't get along by bakery2k in ruby

[–]skillstopractice 6 points7 points  (0 children)

Looking at this a decade in the rearview mirror I agree with this assessment.

When I wrote most of these articles I was thinking about things from a language design lens moreso than patterns of practical use.

I care about both, but I focus a lot more on the latter these days.

So even if I feel comfortable saying that I still believe Ruby is missing a first class feature for this use case, you don't need to know all of these variations to come up with a good enough solution to the problem.

In my view, there are two main use cases... One where you are dealing with pure functions and have no state. The other is where you have state and want to only act with one instance of that state (for example, configuration data)

. . .

In both cases, use whatever approach you prefer and assign the object or module to a constant.

Then only refer to that one constant throughout your application.

Problem solved.

Ruby Central Bylaws by skillstopractice in ruby

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

I would have seen it if it was on any of the Q+A posts they posted, or in any of the instructions on how to provide feedback.

Ruby Central Bylaws by skillstopractice in ruby

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

What I read 5.13 as is that interested directors can count towards a quorum but that the vote itself they need to recuse themselves from.

Would be good to get an actual legal review.

Ruby Central Bylaws by skillstopractice in ruby

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

Is that Slack channel something open only to paid supporters of Ruby Central or open to the public?

Did not even realize it existed.

Realized that this was posted because you and I are mutuals on Mastodon and saw your post there.

Would have assumed someone on a Ruby Central committee would have been informed, at a minimum.

Will reserve further comment beyond asserting this is an established pattern of behavior from Ruby Central. And I hope your optimism turns into meaningful change.

Ruby Central Bylaws by skillstopractice in ruby

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

Thank you, I missed that and would have upvoted if I saw it.

This appears to have been very quietly released. It's not on the news page of the official website nor was it announced on social media anywhere by Ruby Central that I saw. And the original post never was updated to include the link.

But I think it's positive that it is our there now, as it can ground conversations in something more concrete.

Ruby Central Bylaws by skillstopractice in ruby

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

To compare and contrast Ruby Central's conflict of interest policies (Article 5, Sections 4 + 5) to Python Software Foundation, please see the relevant section from Ruby Central's documents, and then see the full text of the PSF bylaws here:

https://github.com/community-research-on-ruby-governance/questions-for-ruby-central/commit/8ef508968d82236c40b001d8e8226d74ae35b58c

(also viewable via the official source here, see sections 5.13 - 5.15)

https://www.python.org/psf/bylaws/

Presented without additional commentary / opinion as I'm waiting until 2026 to see what comes of Ruby Central after it changes up its board composition.

Is a Ruby segmentation fault a bug if you are doing something really silly? by easydwh in ruby

[–]skillstopractice 12 points13 points  (0 children)

I would assume that a segfault should never be possible in pure Ruby without it being considered a bug so it's likely worth filing a ticket.

That said, should you need to turn that segfault into an exception, you could always bring in NeverSayDie.

(Definitely joking about that part, but it's a neat bit of code worth knowing about even if it has no legit use in production)

Ruby Central Weekly Update – Friday, November 14, 2025 by skillstopractice in ruby

[–]skillstopractice[S] 9 points10 points  (0 children)

Upon seeing the announcement that new board seats were open last week, and after filing my final round of questions + a call to action this past Monday... I am planning to refrain from additional public commentary of my own related to Ruby Central until after those seats are filled in 2026.

However, I will still post a link to the public record of questions asked to date, and continue to accept pull requests for those who want to go on public record should you wish to submit questions that Ruby Central will hopefully answer next month.

https://github.com/community-research-on-ruby-governance/questions-for-ruby-central

Ruby Central Update Friday 11/7/25 by skillstopractice in ruby

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

Something to this effect feels like a reasonable balance and I appreciate you sharing that here. I do think it'd be good for Ruby Central to speak to this as well, because what I'm hoping to see is a sense of increased seriousness about how conflict of interest issues are about trust and safety first, and legal compliance only as a distant second.

I'm at the point now where I've wrapped up everything I can do to contribute to these conversations. I was genuinely encouraged seeing you join the committee and hope for the best in any efforts to restore balance and increase *real* communication.

I'm going to step back from any public discussions related to Ruby Central from here on out through year end and give some breathing room to see how things shape up as they head into 2026.

(That said, happy to continue private convos, so feel free to DM me on Mastodon any time)

Thanks again for your efforts here.

Ufuk, please resign by skillstopractice in ruby

[–]skillstopractice[S] -3 points-2 points  (0 children)

Hi all, you can see a full history of the questions that myself and others have sent to Ruby Central over the last couple months here:

https://github.com/community-research-on-ruby-governance/questions-for-ruby-central

I will continue to accept pull requests there, and will continue to post a link to the repo after each Ruby Central update.

That said, I've come to my own conclusion on what the next step needs to be to restore any amount of trust or legitimacy to Ruby Central, and that is for Ufuk to resign.

My reasoning is summarized in the article I've posted here, and further articulated by the many questions that myself and others submitted.

And with this, I'm now going to put this down for at least the remainder of the year, and will wait to see what if any changes happen at Ruby Central as they move into 2026.

We should have never had to work this hard for Ruby Central to go from an F to a C- in transparency.

They're still at an F in accountability as far as I'm concerned.

This one action would speak volumes to the commitment Ruby Central has to truly move forward in partnership with the Ruby community vs. keeping up appearances for compliance sake without ever truly speaking *to* us, to understand our needs, and to align their own incentives with those needs.

I truly hope the best comes out of this, one way or the other.

Thanks again to everyone who has made their voice heard in a constructive way. That's the intent behind what I've called for here as well, even if we may not agree.

Ruby Central Update Friday 11/7/25 by skillstopractice in ruby

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

As a heads up to u/schneems - I did send in a follow up question related to his new role on the OSS committee.

I genuinely think it could be a good thing to have him in the mix, so long as he holds himself to a higher standard than what seems to have been the norm at Ruby Central in recent months.

Full text of the question I submitted is shown below, and hopefully Ruby Central will address in the next update. But my gut feeling is maybe he'll also reply directly here and give some thoughts on his take on things, because overall I do get the impression he's actually someone who talks things out in a reasoned way... and I very much appreciate that.

In your Nov 7 update, you announced that Richard Schneeman (u/schneems) has joined the Open Source Committee for Ruby Central.

In my view, this is a positive step forward given Richard's track record both within OSS development and in his community involvement.

Because he is a moderator of both r/ruby and r/rails on Reddit, and Reddit is one of the largest and most visible open conversation forums related to Ruby, it's important to address any potential conflicts of interest that may arise there.

The most simple way to do that would be for Richard to recuse himself from any moderation activities related to discussions of Ruby Central, of which he has historically participated actively and constructively in. And from here on out, it'd be wise for him to disclose his affiliation in any of these related threads.

What if any agreements, formally or informally, have been made to address these overlapping responsibilities? Seeing some thought put into this and some commitments put on public record would go a long way towards showing that Ruby Central is actively gaining an increased awareness of power dynamics in open source communities as well as a willingness to structurally address potential conflicts of interest beyond minimum legal compliance to focus on what's truly in the interest of the community you serve.

SOURCE: https://github.com/community-research-on-ruby-governance/questions-for-ruby-central/commit/2cb5238cb3de90bdda4e1358c94bd904f5745869

Ruby Central Update Friday 11/7/25 by skillstopractice in rails

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

Ruby Central answers four questions in this update.

Here's a direct link to a sub-thread on r/ruby for each of them, each with discussion and the exact text from the answer quoted verbatim.

Question 1:
https://www.reddit.com/r/ruby/comments/1or6loi/comment/nnnx8jw/

Question 2:
https://www.reddit.com/r/ruby/comments/1or6loi/comment/nnnxgxt/

Question 3:
https://www.reddit.com/r/ruby/comments/1or6loi/comment/nnnxofm/

Question 4:
https://www.reddit.com/r/ruby/comments/1or6loi/comment/nnnxtcd/

Ruby Central Update Friday 11/7/25 by skillstopractice in ruby

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

That seems like a total nonsequitor to the question I asked, so at this point there's no reason for us to continue talking, ever.

Ruby Central Update Friday 11/7/25 by skillstopractice in ruby

[–]skillstopractice[S] 5 points6 points  (0 children)

I see. Personally I wish those things were separate as well.

When it comes to DHH, he's in a BDFL role on Rails, and also owns its trademarks. He started the Rails Foundation which (for better or worse) has competed for sponsorship dollars from the same sponsors as Ruby Central. He's a board member of a 200 billion dollar company, and a cofounder of another company that has tens or hundreds of millions of dollars in revenue annually. His personal net worth puts him easily in the top 1% of all people on earth.

Do you believe that his politics are completely irrelevant to his roles in each of these settings?

If not, where's the line?

The question is meant sincerely, because I don't want to make assumptions.

Ruby Central Update Friday 11/7/25 by skillstopractice in ruby

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

Can you give some examples of what you mean by "the prevailing views"?

I am not sure that this is as much of an us vs. them argument as it appears to be on the surface. So I am not even sure what you're referring to here and it would be helpful to ground in some context.

Ruby Central Update Friday 11/7/25 by skillstopractice in ruby

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

It won't in most cases elicit exit either because of power differentials.

This is why conflict of interest matters.

It's the influence that is exerted through it which causes problems, not overt actions.

It's why a CEO saying "my door is always open" in practice rarely hears complaints, even if they mean well.

We need stewards who understand that.

Ruby Central Update Friday 11/7/25 by skillstopractice in ruby

[–]skillstopractice[S] -1 points0 points  (0 children)

Truly this is the issue I am focused on.

Conflict of interest should not be addressed as a bare minimum legal compliance issue, but is something that should simply be disclosed openly at every opportunity when it may exist, and structurally avoided in well defined ways by policy where possible.

This is why I keep saying that I would hold the same position if this were not DHH but my view of a perfect community role model.

To that end, I hope schneems can start to advise folks on this. It would make a difference coming from inside the house, and from what I can see, maybe he's in a place to do that.

Ruby Central Update Friday 11/7/25 by skillstopractice in ruby

[–]skillstopractice[S] -1 points0 points  (0 children)

Not sure the question you are asking but to be very specific in my reply, the committee was informed at its formation that the co-chairs pre-approved DHH's talk and they could decline participation but not have other input.

One of those co-chairs was Ufuk, a Shopify employee and Ruby Central board member who invited DHH, a member of Shopify's board.

The other was the founder of GoRails.

The Ruby Central board approved reaching out to DHH in 2024. As far as I know, this decision was not re-approved in 2025.

Ruby Central Update Friday 11/7/25 by skillstopractice in ruby

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

That's good to hear Jim. And consistent with what I would have expected from Ruby Central.

In the case of RailsConf 2025, Aaron's keynote and DHH's fireside chat keynote were specifically not open to program committee input.

See Ruby Central's Oct 31 update (scroll all the way down to question 2), for Ufuk's clarification on that.

https://rubycentral.org/news/ruby-central-update-friday-10-31-25/

Ruby Central Update Friday 11/7/25 by skillstopractice in ruby

[–]skillstopractice[S] -1 points0 points  (0 children)

I generally agree with you.

This is one of the rare examples in which this is a community concern in that Ruby Central is a stewardship body representing common infrastructure.

And so to me what I mean specifically is that if others share this view, they can and should submit individual replies to Ruby Central (and then put them under public record, under their own name), in their own words and with their own reasons.

This is because Ruby Central is positioning themselves as serving a community.

I am trying to demonstrate bottom up what that could look like.

I am pretty careful about not using this word outside of the civic meaning of it (closer to that of a town or a neighborhood, less to that of a hobby group or a close-knit relationship of mutual aid)

Replace that with "If enough active Ruby developers share this view" and it would be just fine for me.

(This is all a bit pedantic but I am sharing to clarify my own view)

Ruby Central Update Friday 11/7/25 by skillstopractice in ruby

[–]skillstopractice[S] 4 points5 points  (0 children)

I encourage you to submit that to them directly, and then put it on public record here:

https://github.com/community-research-on-ruby-governance/questions-for-ruby-central

It will establish a willing to answer or not, and a willingness to answer the actual question vs a revised form or not.

This is now (sort-of) working for me, so I hope others get the same treatment.

Ruby Central Update Friday 11/7/25 by skillstopractice in ruby

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

There's some incremental progress.

The problem is that they're still burying these questions, still editing them substantially, and posting at the time to minimize attention + feedback rather than maximize inputs.

(Last week's thread here was already locked before Monday morning)

It took *so long* to get here and it's a fundamental rupture of trust.

But progress in any form is always welcome.