+ Login with
+
+
+
Trustable service landscape
+Imprint
+ +-
+
- Tobias Wilken +
- Ziegeleiweg 29 +
- D-26203 Wardenburg +
- tooangel@tooangel.de +
- +49 160 96657514 +
diff --git a/index.html b/index.html index ff71030..3565bda 100644 --- a/index.html +++ b/index.html @@ -1,19 +1,23 @@
- - + +
+ Login with
+
+
+
+ Login with
+
+
+
+ For decades, open source projects have brought transparency and openness + to development. Over time, certain problems have come to light: +
+ ++ 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. +
+ ++ 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.
+ ++ 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. +
+
+ + 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. +
+ +
+ 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
+
+ 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. +
+ ++ Having clear and automated rules for progressing in open source + projects is just the start. Due to the DevOps (or GitOps) ideas, many + operational tasks are now stored in repositories and applied upon + merge. So the challenge now is building (world driven) services that + operate on these ideas and are only maintained via Pull Requests. This + provides a new level of trust and a new entity + unavailable system data (still searching for a better name). + Passwords, service credentials and the like is data which does not + necessarily have to be accessible by humans; it can therefore be + maintained and used exclusively in the system itself. +
+ ++ For example: In one of the companies I was working for, the employees + were using Chromeboxes. As part of their daily work they had to split + and merge PDFs. There are a lot of (free) services out there that can + do the job but they can't be used due to privacy concerns - What + happens with my PDFs? Do they store them? Do they use them? - I hope + (and guess) that they don't but I can't be sure. +
+ ++ Compare that to a PDF service that is open source, world driven and + uses continuous deployment. No one has access to any credentials and + changes can only be done via public Pull Requests - That sounds far + more transparent to me. +
+In my mind these examples use:
++ The web service itself is World Driven but can I trust the other + parties? Why not build the infrastructure in the same way? Using IaaS + instead of higher level managed server is a lot to do but it is doable + (I know, I've already built a PaaS). In my opinion, a World Driven, + fully automated IaaS is more challenging. +
+ ++ The question now is how deep to dig? You've scrolled this far, how + much futher along this journey are you willing to go? We'll be pleased + to have you regardless. to come with me? +
+
+ Login with
+
+
+
+ World Driven does not store any private data. World driven stores + credentials to access GitHub data and proxies a subset of this data, + like the GitHub username. +
+ ++ In certain cases the data could be cached for performance reason for + maxiumum 30 days. +
+ ++ No log data is stored by the application itself, the application is + hosted on heroku, where access logs are made available for a short + amount of time. These logs are available via the + public admin interface. +
+ ++ Cookies are only used for technical reason, storing a session bound to + the GitHub keys. +
+ ++ The Website is not inteded for children under 16 years of age. If you + are under 16, please do not use this Website. +
+ ++ The application is automatically deployed from the master branch of the + GitHub repository, + if you want to double check look there. +
+ ++ If you have any complaints regarding our compliance with this privacy or + want to discuss something you should first contact + Tobias Wilken +
+- Worlddriven is a democratic development platform where decisions are - made collectively through pull requests and time-based voting. -
-- This admin interface allows you to manage repositories, - configurations, and monitor the democratic development process - across the organization. -
-