Per the discussion in the forum governance call, opening this thread to start discussion specifically on ad hoc / drive by (so not necessarily considered official “work” by “workers”) code contributions.
This discussion is about a amazing-problem-to-have situation of having a bunch of people willing and capable to do slivers of work on the codbase, and having to decide which to say yes and no to.
Possible motivations for ad hoc work:
- Someone is polishing their resume and wants to show off some open-source code contributions
- Someone wants to learn the codebase to see if they want to get more involved
- A user is annoyed by some current functionality (example, a bug) and wants to change it note: this is different than the first two situations
- someone is using or wants to use the resonate API for something, and the change would make their third-party work easier or possible. Their work on the resonate codebase is a requirement for their non-resonate related goal.
Assuming this person has done the work, has made a pull request, and there are no technical objections to including it (an existing developer(s) has looked at it and finds no issues), what should this persons next steps be to get it merged and deployed, or to be told their work won’t be merged and deployed?
Example reasons to say yes:
- everyone likes the new work and are happy to have it
Example reasons to say no:
- it’s not on the roadmap, and goes against the roadmap
- dealing with this change will endanger a deadline
- nobody wants this change
- this new work makes things more complicated and there’s not enough resources to maintain this new stuff
things done in other communities:
centralized ways:
- the ad hoc contributor socializes their proposed change in the forum, then the community (importantly - not just the developers) votes to accept it / deny it. This means there’s a voting mechanism in the forum, mailing list, whatever, and the community is used to using it regularly for other day-to-day decisions.
- whoever the product owner is makes the decision that this change works against the roadmap and the work is not merged.
in both of the bullets above the technical owner of the project has veto power, and in the second the product owner (the owner of the backlog) has veto power.
fully-decentralized ways
- something like sourcecred marketing video, better sourcred presentation (@datafruits maybe you have some ideas here)
- so many DAOs in which members use their tokens to vote on the day-to-day proposals (example - Decentraland )
things done in other communities to mitigate random unwanted changes from being proposed:
- there’s an easy way to onboard developers looking to completely independently take on any small task - the community maintains and prioritizes a “good first issue” list of small issues. This will be the honeypot for the people looking for any small thing to work on for their own reasons.
- have semi-regular (quarterly?), publicized (social media, email) on-boarding sessions for interested parties, in which the goals of the project are also discussed. This will allow for discussion about why and how things are done the way they are, tips and tricks, plans for the future, etc.
todo: circle back at 2021-10-02T04:00:00Z
cc: @auggod