Discussion: Extending Bulma, Governance, & Design Patterns

[dfee]

I want to open a conversation and collect thoughts from the community who uses rbx and get insight into what the community wants in terms of extensions – and how we can maintain this together as a community.

For example, I added Badge, Divider, PageLoader and Tooltip to the rbx ecosystem from Bulma-Extensions as they only incorporated SASS changes. I have not incorporated any extensions that require migrating JS code. Largely, this is because I fear that the amount of maintenance for one-man maintaining this might be a bit much.

In addition, @neilime added a pull request yesterday for a NotificationToast component that does incorporate some some TS logic. That's great. But it raises some interesting questions:

1. how would we like to handle stylistic deviations (or extensions) from core Bulma?
2. what is reasonable to include in rbx vs. what should be an add-on package?
3. how do we reconcile the future of Bulma and any forward breaking changes it makes that will impact work we've already done on rbx. (i.e. what's our plan for if Bulma decides to implement a design-pattern for toast in the future)?
4. (perhaps most importantly) how can we bring more people into the rbx governing community?

If you want to participate in this discussion, please join in. Also invite other people into the discussion!

[dfee]

Some initial considerations:

1. I created a GitHub Organization rbx-framework and will likely migrate rbx into that organization.
2. I want people who contribute code to also assume some sort of maintenance liability for the code they've added.
3. I want some thought-out process for how we incorporate community changes and feedback into the future of this project.

[pauleveritt]

Hi @dfee is this still under consideration?

[samtgarson]

FWIW, my thought on this kinda thing is always to make it opt-in, using some kind of plugin or extension system—as soon as you deviate in this way, you will inevitably find users who don't want the additions or think they should be done differently. Maybe this is what you were referring to with the new Github org...

Also, on your point 2 in your comment (maintenance liability) I understand what you're going for here but this sounds a bit like introducing a "git blame" culture, which I don't think would be too healthy. Other OSS orgs I've used tackle this by having a "community" repo of plugins/extensions which are "officially recommended" but not supported formally by the core library maintainers (although they do provide support, etc).

Hope this helps! Thanks for your work on this ✌️