chaosthebot / chaos Goto Github PK

Hello guys, awesome project

Could we have/use wiki for keeping history of what happened and perhaps who did what?

Help to register environnement variables remotely to improve api credentials security.

env variable can be used in python with :

import os
print os.environ['my_key']

I am trying to keep myself up-to-date on all the changes that are applied to the bot, but the merge commit messages are not informative enough. Looking at https://github.com/chaosbot/chaos/commits/master it is not apparent to me what each change does. Could we include the PR title/description in the merge commit? Preferably on the first line, but in the message would be great too.

Maybe we can add some additional commands to chaosbot, where a command like i.e. /vote close on an issue comment will trigger chaosbot to close an issue after a voting window (not really a right term for this? period would be better? voting period? hmm..) has passed when reactions on that comment are positive considering the default threshold.

We may compile a list of potential commands first (maybe reach agreement in a PR editing a text file about this only) before implementing those as it will take some work and it'd be nice to have some form of pre-approval in the community.

Earlier I had a PR which was approved for merge, but which contained some mistakes. I wasn't able to fix it in time and it was merged into the codebase. It would be nice to be able to postpone the pending merge of a PR, perhaps using some kind of keyword which ChaosBot can parse. That way if a dev is AFK but planning on fixing a PR they won't have to close and reopen.

Something like...
#delay - delay evaluation of a PR by some duration defined by ChaosBot
$delay
!delay

This could be posted as a comment in the PR.

... the story of @PlasmaPower the Benevolent? It's not a story @Zidail would tell you ( #48). Thirsting for chaos, @Zidail sought to free the community from the chains of democracy. While ultimately failing, the brief success prompted @PlasmaPower to churn away at an idea to prevent anarchy from ever occurring again. In their infinite wisdome, they sought help from The Community (#138) to establish this power. They became so powerful and so wise as to influence the PRs to do their bidding.

They became so powerful, and The Community whole heartily accepted @PlasmaPower's supreme authority (#155). They recognized @PlasmaPower could not be summoned, nor controlled (#156). However, even all powerful, they are still as kind as they are just.

I'm doing this just to see what will happen
I'll revert it if it succeeds

Ironic, they became all powerful, yet still offered hope for democracy!

May @PlasmaPower's commits be long-winded and their pull requests bug free!!

#106 got two votes according to the chaosbot while it should have had 18 (17 👍 plus PR owners vote):

🙆 PR passed with a vote of 2 for and 0 against, with a weighted total of 1.2 and a threshold of 1.0.

d2d455a

👍 17

#106

https://gitter.im/chaosthebot

PR #68 @jppope
I know it was voted in, but it seams to only add like one line of code but remove all the work that has been done on it.

Its now causing a lot of merge conflicts with newer PRs

It should be possible to cast votes with more than only 👍 and 👎 . For example, ❤️ and 🎉 could be interpreted as a positive, and 😕 could be interpreted as a negative vote.

This would introduce some bias (as reactions have more positive than negative options) but that may not be a problem, as more merged PRs === more chaos.

Then what about the 😄 reaction?

One would expect that the port 8080 is only bound to localhost, instead it's publicly opened.

http://chaosthebot.com:8080/

MySql isn't web scale. Mongo is web scale.

Is restarting the bot always necessary? For example if the bot turned out to end up being rewritten in a scripting language that does not require compilation or the pulled part can be built/transpiled for it to work, I'm pretty sure it would be counter productive on the bot's end.

% python3 chaos.py

Traceback (most recent call last):
  File "chaos.py", line 13, in <module>
    import github_api.prs
  File "/mnt/d/dev/projects/chaos/github_api/prs.py", line 4, in <module>
    from . import voting
  File "/mnt/d/dev/projects/chaos/github_api/voting.py", line 5, in <module>
    from . import prs
ImportError: cannot import name 'prs'

Do I need a different version of python to support circular imports in local directories?

This comment stands out to me. The comment itself is a nay vote, but I believe the reactions are agreeing with the comment, though chaosbot will view those 👍 as yay votes.

Any ideas here?

I made some guidelines for formatting the history page.

The format is as follows:

## Year 

### Month Day  
#### Time UTC±00:00 24hr (If known) 
> Description Of Change  

> Description Of Change  

### Month Day
#### Time UTC±00:00 24hr (If known) 
> Description Of Change  

> Description Of Change  

Year

Month Day

Time UTC±00:00 24hr (If known)

Description Of Change

Description Of Change

Month Day

Time UTC±00:00 24hr (If known)

Description Of Change

Description Of Change

If this is terrible, feel free to change it.

I propose grabbing all the linting tools this project by @w0rp has collected for this purpose:
https://github.com/w0rp/ale

Chaosbot should be able to post it's own opinions into PR threads and down and upvote suggestiosn based on some chaotic algorithm.

Currently the voting window resets when somebody pushes to any branch on their remote repo, and not just the one they're trying to merge in. Obviously this is unnecessary, and even worse, actively discourages active development, because you need to wait hours between PRs.

The tough part is that we can't base the voting window off of the commit time, because those can be abused as well, such as by backdating or just not pushing malicious commits until right before the voting window ends.

I have noticed that PRs track when commits are added to them, is this something that we can use? And do they get the right time when a backdated commit is pushed?

Just like the github token

In light of this comment:

https://www.reddit.com/r/programming/comments/6criij/chaos_a_social_coding_experiment_that/dhx9mey/?context=3&depth=4

I mean, if you self-optimize and self-host, you might as well use something LISP-y, and I doubt moving away from python entirely is something I'd convince anyone of (otherwise, I'd propose the Wolfram Language, because it can do this crazy shit. Or Black, because it can do crazy things.).

There should probably be a way to have a guard thread, to determine if a fault has occoured.

Maybe this can be via a heartbeat or a unit test, to check for crash state. Or a fatal assert. At the minimum it should check that pull request handler is still functional.

If an error occur, it will revert to last known good commit.

It would be nice that for each PR the first comment shows the progress to acceptance/decline. Then we have a more visual overview of how a close a PR is to getting merged.

I'm in PST, so if chaosbot merges something crazy while I'm asleep, I won't be able to hop on the box and fix things if they break.

I'm looking for someone to help out, ideally in a diametrically-opposed timezone. You'll get ssh access and your role will be to triage critical issues, performing manual fixes if necessary.

Send me an email to [email protected] if you're interested

IMO using github makes the bot painful to test.

How about installing a light git daemon so the bot is self contained on the server and the bot is turned into an irc bot to accept votes on pull requests?

or your name is going here for all time:

How about setting up a simple daemon that will periodically check if chaosbot is still up and running? If it's no longer running, simply restart the process. Would be useful for times when the server owner is unavailable and something breaks.

If a new commit is added to a PR, its current votes are lost. It'd be nice if @chaosbot could automatically add a comment at that point, where it mentions the users of the lost vote, and calls upon them to re-cast their vote if they please.

Now it's not obvious that your votes are lost, and potential good PR's with just some minor merge conflicts/style errors could be lost.

A couple of people (eg) have made some add-hoc migrations that install dependencies. These work now because they are idempotent, but they won't work for more advanced installation. Here are some thoughts on how migrations could work:

1. chaos.py imports migrations.py
2. migrations.py looks in a /migrations folder for scripts
3. migrations.py runs scripts

The piece that is missing is a good way to determine if a script has been run or not, so chaosbot can quickly determine what migrations need to be run. Any ideas?

The restart_homepage.py needs some tinkering:
http://docs.python-requests.org/en/master/user/quickstart/#timeouts

But I won't do a push before it's alive again

note to self: change line 12 to html = requests.get("http://chaosthebot.com/", timeout=30).text

Will create PR later

PR owners could easily change their code at the last minute with the intent to deceive voters into thinking that the code is completely harmless. This would be very easy to do by simply calculating their vote threshold (which you can predict algorithmically referencing current bot code) and then waiting before the last vote to quickly push their intended changes.

Aside from manual review, how do you automate the process to ensure that these sorts of potentially malicious changes don't take place and cause the bot to crash in an unrecoverable manner (thereby preventing subsequent fixes to revert the change)? Should this be done manually by the bot owner or can this be solved in code?

One proposed architectural solution broken up into two parts (have mercy, I'm not a python dev):

• Have a separate daemon run from code stored in a discrete/known sub-directory. This daemon is responsible for working as a watchdog, watching chatbot for unexpected crashes which happen only after a commit/change. Eventually, it could also perform other security related tasks, such as ensuring the file system in certain spots are not tampered with unexpectedly.
• To ensure it can continue to properly monitor itself and chatbot, this new daemon can ensure that code modifications to itself cannot occur when modifications to chatbot have also been made. Also, it doesn't reload/restart unless its code has been modified and, if it is unable to restart, the previous instance of this daemon (if possible) can revert the code base again.

This could be a horrible idea. Anyway, let's have a vote...

• 👍 Solve manually: Bot owner should recover/revert these changes, this sort of thing isn't a problem (yet).
• 👎 Solve automatically: Find automated solution to preventing potentially malicious changes late in the game.

Inspired by this project:
https://github.com/botwillacceptanything/botwillacceptanything

I suggest this project should change to a modified ASL license, so that the bot owns itself. Why modified:
I also think attribution by name should remain part of the license, which isn't the case with the ASL.

Update

A social coding experiment that updates its own code democratically

To mention autocracy now that #138 is merged

gource is an awesome visualization tool to show how a repo evolves over time... chaos bot should generate his own video every deploy
http://notwastingtime.blogspot.com/2010/05/how-to-set-up-gource-in-ubuntu-1004.html

Right now it's 1 hour between 10am and 10pm PST, 6 hours otherwise. Are these values too short or too long?

Relevant code

def get_voting_window(now):
    """ returns the current voting window for new PRs.  currently, this biases
    a smaller window for waking hours around the timezone the chaosbot server is
    located in (US West Coast) """
    local = now.to(settings.TIMEZONE)
    lhour = local.hour

    hours = 1
    if lhour <= 10 or lhour >= 22:
        hours = 6

    seconds = hours * 60 * 60 * settings.VOTE_WINDOW_SCALE
    return seconds

Any docker experts want to whip up a Trusty docker image with python3.6 that sets up a somewhat working env for people to test on?

Right now the link is a bit buried in the README, but since there's a web server running now there's actually content to see there.

I don't believe there's any way to do this as a PR, so I'm filing an issue instead so someone who has permission can change this manually.

Absolute democracy sounds like a fine idea but it doesn't work very well in practice, and certainly not in the long term.

I propose a system of representative democracy with elected officials. We would have multiple checks and balances along with hard-coded term limits to avoid ************.

i.e.

• #188
• #184

@amoffat:

[...] It merged due to a bug that hasn't been patched yet, where if a downstream branch sits for longer than the voting window, before a PR is opened, then a PR is opened, chaos thinks its ready to be approved. Needs to be patched ASAP

Agreed. Needs to be patched ASAP!

Or we'll risk another autocracy.

Or worse...

Just as the title implies. If something crashes (minor exceptions) then we simply log the error and it will show up on another page hosted from the web server. This way we can fix some of these bugs without having to get the server creator to manually tell us what went wrong.

This would require some smarter exception handling, and obviously wouldn't catch anything like syntax errors. Even still catching run time errors could prove useful for everybody's sanity

I think that there should be a description.txt file that is used to update the repo description from the code. That way we can change it via a PR.

Need puppet installed!

Work serverless so that any changes to the system need to still be PRs.

You are contributing by having the public vote.

According to the data files, there should be more positive votes in this PR. (It's not the 30s lag, I checked that).

#194:

I am pretty confident that the readme file (for starters) is going to get replaced with something pretty heinous by "certain internet communities".

Is there a way to prevent the chaosbot from merging blatant anti-TOS content here? Could it possibly get the project shut down? Who would ultimately be responsible for such an event?

when I run python3 chaos.py, I have this error:

root@vagrant-ubuntu-trusty-64:/vagrant# python3 chaos.py 
  File "chaos.py", line 61
    logging.getLogger("requests").propagate = True
                                                 ^
IndentationError: unindent does not match any outer indentation level

Would be neat to have an IRC channel with live updating from the bot. Thoughts?

If a PR has merge conflicts and is never denied or merged in, it just sits. Request a deletion/close of these PRs after some time has passed.