Login with

Phase One: Dynamic Code Ownership

The Challenge

For decades, open source projects have brought transparency and openness to development. Over time, certain problems have come to light:

• Contribution can be frustrating due to unclear processes

  For example, I had a couple of cases where contributions / Pull Requests were missing communication or agreement on when to merge between the maintainers or were just ignored.

• The power of progress is restricted to a certain group

  Independent of previous contributions, the direction of a project is decided upon by a limited number of people or companies with possibly hidden agendas.

• Projects die even with interested contributors

  The owner of the project is not interested any more or has become sidetracked and so no longer manages any contributions

• Project owner change leads to uncertainties

  One of the bad examples: The event-stream incident

An Idea

Establish a contribution-based, weighted voting system for time-based auto-merges.

Nice sentence, but what does that mean? In the following, I'm using the GitHub vocabulary but I hope this can be easily translated into similar systems:

Contributions are presented as Pull Requests, the Pull Requests are automatically merged after a certain time by the world driven auto-merger. Contributors have the possibility to vote on the merge by reviewing the Pull Request and either Approving (for) or Requesting Changes (against). The weight of the vote depends on their previous contributions: The more contributions the reviewer has made the more their vote can speed up or slow down the merge date.

If a certain threshold of negative points is reached, the merge is cancelled.

An Example

For different projects a different configuration than the one given here may make more sense, but this example will help explain the process regardless of the specific configuration chosen:

Let's say that the merge duration is 10 days long, the weight is the number of commits on the repository and the project itself has 1000 of them.

Alice sends her first Pull Request to this project. Bob, one of the active contributors who has 400 commits, likes the changes and votes to 'Approve' them in his review. As a result, the time until the auto-merge completes is reduced by 4 days: 400 (contributions from Bob) / 1000 (overall commits in the project) * 10 (the merge duration).

Carol, who is fairly new to the project but already has 100 commits, doesn't like the styling and wants the code refactored into methods. Her 'Request Changes' review increases the time to merge by one day: 100 (contributions from Carol) / 1000 (overall commits in the project) * 10 (the initial merge duration).

Alice agrees to Carol's suggestions, prepares the changes and pushes them so the timer is reset due to code changes.

Bob agrees to this altered version of the Pull Request (-4 days) as does Carol (-1 day). So, overall this Pull Request now has 5 days until it is merged.

Next time Alice, due to her now merged contributions, has the ability to vote on any future Pull Requests. This means she can have some responsibility over the progress of the project.

Of course, if 100% vote for a Pull Request it is merged directly.

Current Status

The auto-merger is working on itself and a couple of other projects as well; therefore, I would say it is in a prototype state.

A status check is used to show the current time until the Pull Request is merged and provide a link to a detailed breakdown of how that time has been calculated.

Why?:

• Due to the clear rules, it is easy to see what happens with your PR and when it will be merged.
• Some open source projects struggle with their maintainer. This way others can still drive the project forward in their absence.
• Weighting the votes gives the main contributors the most power to either stall/block bad PRs or to speed good ones up. In addition, it can motivate people to contribute more to the project in order to increase their own weight.
• One fundamental question is how this system interacts with the idea of a repository having an owner? Currently, the owner of the project has full control and can stop or speed up anything they wish. It would be nice if they didn't have to.

There are definitely ways this system can be tricked with certain types of behaviour but that's not the idea behind using world driven. Working on an open source project is all about collaboration so most, if not all, of this unwanted behaviour can easily be solved by communication.

Current Rules:

• 10 days (at least more than a week) should give everyone enough time to look into the Pull Request.
• The time is increased for each commit in the Pull Request. This is because multiple commits indicate a certain degree of complexity behind the request hence reviewers will need more time to check it.
• GitHub's reviewing functionality is the perfect place to discuss the PR and express your preference (GitLab is the same but that feature is not yet implemented).

This project is `world driven` itself. If you like, jump in and be a part of the World Driven project. You can also join the discord server or simply say hello to the project's creator Tobias Wilken

A Speculative Future...

The further phases are only speculative and lay blurry upon the project's horizon. Scroll further and our current ideas will be clarified, join us and you can help shape them.