Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Help stale Open Source projects become active again by giving them democracy! #574

Open
hongaar opened this issue Nov 1, 2017 · 19 comments

Comments

@hongaar
Copy link
Member

hongaar commented Nov 1, 2017

Just reviewed a couple of my PRs on various open source problems, most of which didn't get any comment/attention from the project maintainers. This made me think about Chaosbot again, and I think that many OS projects can really benefit from giving contributers some more influence over merging PRs/managing issues, etc.

We already had a nice thing going on, what if we try to move it towards a SaaS solution aimed at helping out OS projects on Github, maybe even publishing it at the GH marketplace if we're successful?

We'd need to have a good functional design first, and this project should then really aim at creating a finished/usable product instead of having more of a focus on being an experiment.

Just a thought... maybe with some combined development time we can actually make something useful!

@andrewda, @xyproto, @rhengles, @PlasmaPower, @eukaryote31, @rudehn, @MUCHZER, @mark-i-m, @phil-r, @hongaar, @md678685, @Smittyvb, @Swizz, @Redmega, @mpnordland

@mdcfe
Copy link
Contributor

mdcfe commented Nov 1, 2017

I think this was one of the original plans for ChaosBot v2. I think one of the reasons that v2 never materialised was that many people didn't feel the same way about the brand new, heavily-discussed piece of software compared to the chaotic experiment of the original ChaosBot, and so fewer people were interested in investing the time to work on building the new version from the ground up.

That's not to say I don't approve of the idea - I'm all for it, but I'm concerned that there won't be enough interest to make it sustainable, and it's unlikely to be the fun, attention-gathering experiment that the first ChaosBot was.

@Swizz
Copy link
Member

Swizz commented Nov 1, 2017

I think the v1 of ChaosBot was a success because all the core was here.

OSS contributors are sometimes afraid about making the thing from scratch. This is always more easy to make a PR to update one thing. Pretty hard to coordinate a thing from scratch.
Lot of the most famous OSS projects were at the start built from one man.

@mark-i-m
Copy link
Contributor

mark-i-m commented Nov 1, 2017

After some thought, my conclusion is that this would only work under a few conditions:

  • The project is very thoroughly tested, and tests are required before any merge: this forces good code quality. One of the reasons I think we (especially me :P) broke chaosbot so many times was that we did not strongly test most things. Personally, I would be unwilling to use any project in my codebase that breaks every few commits...

  • The owner is willing to let others determine the fate of the project. One way around this would be for you to fork the project and setup the chaosbot yourself. In fact, you can already fork the repo and improve it yourself. One question is how does chaosbot improve over this paradigm?

  • Users are honest. Checking for power grabs is hard and exhausting. And it only takes one malicious contributor to break lots of stuff. I don't know how to make chaosbot byzantine fault-tolerant without lots of voters/reviewers. One idea is to require an approved github review to vote for an issue (i.e. the only way to vote for something is to review changes) and keep the 👎 reaction on the PR for voting against.

  • There is enough interest in the project for a vote. I don't think this will solve the problem mentioned by @hongaar in the opening comment unless there are a lot of people that similarly want a given change enough to review and vote for it.

@hongaar
Copy link
Member Author

hongaar commented Nov 2, 2017

@md678685 I agree that it will be more difficult to find developers wanting to donate the time for a project with a more rigid goal. It won't attract much attention (at least not compared to the v1 experiment) but I don't agree that it can't be fun, we'll be working on something which could be used for many real-world projects.

@Swizz true point, and it will be challenging! Even better if we can show it can be done in a different way!

@mark-i-m respectively:

  • 100% agreed. GitHub let you control this in a nice way already, by using merge checks on CI containing tests + code coverage analysis.
  • Collaboration. Forking and improving doesn't give back to everybody. Discovering notable forks on GH is a pan.
  • Something along those lines, combined with a meritocracy (which worked pretty well I think, maybe with more emphasis on recorded contributions to a project). Also, protected branches in GH could help? So i.e. only certain users can merge to the master branch.
  • Chicken and egg? As soon as contributors can have more direct influence, their involvement with the project might increase, the project evolves faster, and more users (and potential contributors) are attracted.

@mpnordland
Copy link

mpnordland commented Nov 2, 2017

@hongaar At least from my perspective, it will be easier to attract developers because we would have a defined goal, which makes it easier to show people how they can help. The easier it is for someone to contribute the more devs we'll have. I think this is a great idea.

@mdcfe
Copy link
Contributor

mdcfe commented Nov 2, 2017

@mpnordland I suppose you're right - I was thinking more short term, but having a clear goal would probably attract more long term contributors.

@mark-i-m
Copy link
Contributor

mark-i-m commented Nov 2, 2017

Something along those lines, combined with a meritocracy (which worked pretty well I think, maybe with more emphasis on recorded contributions to a project). Also, protected branches in GH could help? So i.e. only certain users can merge to the master branch.

I guess one thing I would change is that rather than making it a meritocracy, maybe contributors can be elected a "review commission" or something after they have contributed a PR (or some other minimal requirements)... We could also have the ability for an elected reviewer to step down. The idea would be to try to involve more people in the reviewing process and reduce burden on those who might have other time commitments...

@eamanu
Copy link
Contributor

eamanu commented Nov 2, 2017

I think that with Chaosbot we develop an interest system voting. But, I felt that it didn't have a goal. We have to make a list of goal for the future. What do you think?

@Redmega
Copy link

Redmega commented Nov 2, 2017

I love these ideas and reviving Chaos, I've been so busy with work the past few weeks/months I've barely had time for the OSS repos I maintain, let alone this project. Hopefully things will change soon.

@yet-another-account
Copy link
Contributor

I personally think we should do something involving decentralization. Since the idea of chaos is to be self governing, the fact that it relies on a single cloud container is sort of a shame.

@mark-i-m
Copy link
Contributor

mark-i-m commented Nov 3, 2017

blockchain bot!

@syvb
Copy link
Contributor

syvb commented Nov 4, 2017

I made a Node.js version: Chaosthebot/chaos2. Right now, it only works when I run on on my computer, because it hasen't been put on the cloud server, and we need a OAuth token from @chaosbot.

@mdcfe
Copy link
Contributor

mdcfe commented Nov 6, 2017

I don't think the server is still around, so we'd need a new server to run the bot on.

@mark-i-m
Copy link
Contributor

mark-i-m commented Nov 6, 2017 via email

@Swizz
Copy link
Member

Swizz commented Nov 6, 2017

And how about the OpenShift "free for open source" plan ?

https://www.openshift.com/grants/

@yet-another-account
Copy link
Contributor

yet-another-account commented Nov 7, 2017

I still think we should make it decentralized, running it on a single cloud container makes it a lot more vulnerable.

@yet-another-account
Copy link
Contributor

Still, if we have to do it on cloud, I could run an f1-micro for it.

@syvb
Copy link
Contributor

syvb commented Nov 7, 2017

@chaosbot @amoffat Can you get an OAuth token for @chaosbot? Preferably, one with all permissions.

@hongaar
Copy link
Member Author

hongaar commented Nov 7, 2017

@Smittyvb I really like the idea of developing this in Node.js! 👏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants