Collective / Delegated Decision Making on Ad Hoc Code Contributions

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

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

3 Likes

I’ve explored sourcecred a little bit, its a really interesting project imo.
It seems like it could really help at scale.

I guess maybe for where we are at now something between fully-dentralized and centralized workflows might be best?

I wonder what orgs like disco.coop think of sourcecred or if they use anything similar. Disco.coop has been mentioned on sourcecred forums before at least.

1 Like

Any notes per ‘circling back’?

So after some real-world experience, my #1 observation:

There’s not enough bandwidth to do code review and testing for even small contributions, so anything not in the official roadmap (whatever the current epic is) is and will be deprioritized. This is to be expected - the official roadmap shouldn’t be derailed by every little request.

However if there were some other volunteers to code review and test, then it would help reduce the risk from any new PRs / contributions / ideas, perhaps making them more likely to get into the next development cycle.

If there’s still a volunteer list available, perhaps assembling a monthly “testing squad” would help with this issue? The testing squad would ideally be equally parts fresh eyes / drive-bys and jaded users.

edit: although testing squad idea seems unrelated to the decision-making process, my thinking is that pausing to consider even a small proposed change takes time, especially when the thinker knows there’s has been no testing and there’s going to be no subsequent testing. It’s enough of a mental load to make anyone think “i’ll check this later”. Having a squad who can have at least one person validate the new item on their local machine (best), on ninja, or on the beta app would help spread this responsibility.

3 Likes