- the maintainers of rubygems spent countless hours doing work for free that benefits the whole ecosystem
- the volunteer members of Ruby Central spent countless hours doing work for free that benefits the whole ecosystem
- the same cast of people moving in and out of paid, volunteer, and board seats (across 2 separate orgs) over 10 years makes the authority confusing to the general public
- Matz and DHH cosigned that Ruby Central is responsible for the project
- Matz and DHH don't have specific authority over these particular github repos or github orgs
- Cosign from community leaders signals what will happen after the dust settles
- alternative paths to achieve the same end result were possible, but all paths had trade-offs
- no one has a "right" to be paid for working on open source
- it is good to compensate open source maintainers for their work when possible and incentives align
- there is a non-monetary, soft power benefit to working on high visibly or critical infrastructure
- Rubygems.org can run without Ruby Central
- Rubygems.org would be better with a healthy Ruby Central
- alternative gem sources help build resiliency
- alternative gem sources increase surface area for supply-chain risks
- alternative gem sources provide healthy competitive pressure for improvements
- alternative gem sources splits resources and divides community
- sponsors should give or rescind funding based on how an org operates or aligns with their goals
- companies that are "doing the right thing" by sponsoring open source are unlikely to continue doing so if they are vilified
- community members are free to criticize corporate sponsors
- its reasonable for companies to prefer in-kind work to "blank check" donations where they have no influence on the direction of work
- board members naturally would advocate for their employer to support a cause they believe is aligned
- board members may have conflicts of interest when employed by sponsoring companies
- open source projects have long operated under informal governance
- open source projects that reach certain status have transitioned to operator agreements/CLA, and often lose contributors in the process
- slow and "corporate" communications can seem out of touch with the community
- slow and "corporate" communications can protect individuals in the community from harassment
- community-based organizations are held to a higher standard of openness, communication, and accountability
- no individual community members have the right to have their specific questions answered or private meetings/documents shared
- there are legitimate supply-chain risks that have been increasing in frequency
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Really digging this pattern for organizing different 'features' of a model.
Keeps related methods together and makes it easier to find relevant code as the codebase grows. Plus I can separate out test files by feature.
Example: Tasks::DueDate
Tasks originally just had a due_date field. Eventually that grew to also support relative due dates ("10 days from start"). And we wanted a handful of helpers like `due_this_week?` and `overdue?`.
100 lines in a well-name module > 100 lines in the model
We can write a bunch of tests in test/models/tasks/due_date_test that are specific to due date concerns. You don't have to work within a 500+ line mega test.
When navigating the code base, you can fuzzy find "due date" and get see all the context, all in one place