💻Development Process

So you've joined the Enoch Dev team and finished the Getting Started instructions. How exactly does the team work to implement new features and fix bugs? Read on to find out.

Testing

Changing the command prefix

Before testing new Enoch bot commands, developers should first change the command prefix. Located in the ./lib/bot/__init__.py file and below the imports is a variable named PREFIX. This is the string that goes before a Discord message to indicate that it is a command. + is the default prefix for Enoch (ex. +ping). Developers should change this to a different string, like -, to avoid also calling the official Enoch bot along with the testing bot (ex. -ping).

Things to consider

• Edge cases - Try to consider the entirety of inputs users can pass into command arguments. What if they pass none? What if they pass too many? What if they pass the wrong type? Your code should be able to handle these cases - try to break the bot now so that it doesn't break in production!

• Run time/efficiency - Especially for code relating to the Google Sheets API, remember that we want the bot to respond quickly and accurately to commands. It should also be able to schedule students and teachers relatively quickly. Consider using a different algorithm, model, or data structure if things are getting too long.

• Ease of use - Most of the people using Enoch have never used Enoch before. Chances are they also have never interacted with a Discord bot before. Thus, you should aim to make the bot as user-friendly as possible. Make command names short and obvious in terms of its functionality. Send informative confirmation or error messages. Ideally, users should never need to visit the documentation unless they're really interested in the different commands Enoch offers - they should be able to explore directly in Discord.

• Reliability - Enoch should consistently produce accurate results.

Writing the Documentation

Why write the docs?

Writing documentation is important for a variety of reasons, including:

• Having a record of changes to the bot

• Explaining the different commands available and how to use them

• Transferring knowledge between older developers and newer ones

When should I write the docs?

It is the responsibility of every developer on the Enoch team to contribute not only to the codebase, but also the documentation. You should write documentation for features of the bot that you wrote code for when a new version of the bot is being tagged or released.

How do I write the docs?

How to use GitBook

Check out GitBook's documentation.

Process for writing the docs for a new version of Enoch

1. Update the Changelog. Use the previous examples to create a section for the current version on the Changelog page. Summarize the changes from the previous to the current version.

   • It may help to use the compare feature on Github (ex. comparing v2.2.0 to v2.2.1). When writing the documentation, you'll want to compare the previous version to the current one.

   • Looking at the closed pull requests on Github may also be useful. Use the milestone filter to find the PRs specific to the current version.

2. Update the Commands Reference to reflect the new, deleted, and changed commands. Follow the format that's already been established.

3. Click the Submit button on the bottom to create a new change request. This is basically like GitHub Pull Requests, but for GitBook.

   • Note: If you need to come back to the change request later, make sure to click on the branch icon on the top right of the page editor and click on your change request to edit those changes (otherwise you're creating a new draft).

4. Merge the change request when and ONLY when you are satisfied with the changes that have been made. Merging basically makes the updates go live onto the internet.

5. Create a new variant in the Enoch Bot collection with the name of the version (ex. 2.3.0).

   • Make you DO NOT add a "v" in the front because it can easily be confused with the tag of the same name.

6. Publish the new variant in the Enoch Bot collection once you're ready for it to be public.

7. Make sure the current variant is listed at the top of the variants list dragging and dropping it in the Enoch Bot collection.

8. Copy, paste, edit, format, and publish the changelog for the new version to the #changelog channel on the Enoch Developers Discord server.

   • Hitting Send and then Publish will send a copy of the message to all channels that follow our changelog, which includes the C4T #followed channel and the C4T Community #general channel.

   • If you accidentally publish, don't worry. You can still edit the message as needed, and it will update the other messages.

README.md and the Welcome GitBook Page

The README.md file found in the root directory of the project repository is basically a summarized and more general version of the Welcome page on GitBook. It should be updated accordingly.

license.md and the License GitBook Page

The license.md file found in the root directory of the project repository and the License page on GitBook should contain the same information at all times; that is, if one of them gets updated, the other should also be updated.

Running the actual bot on AWS EC2

Once you have SSH'd into the EC2 instance:

1. Run cd enoch-bot to go to the project's root directory, which contains the code from the GitHub repository.

2. Run git pull to make sure you have the most up-to-date code.

If there is no instance of the bot running:

1. Run tmux to create a new tmux instance (basically a separate terminal with the same files as the original terminal) so that we can run the bot in the background.

2. Run python3 launcher.py to launch the bot (similar to steps above for running it on your local computer).

3. Press Ctrl + B then press D to keep the tmux instance running in the background and return to the original terminal.

If there IS an instance of the bot running:

1. Run tmux attach -t 0 (you could theoretically have multiple tmux instances, in which case replace 0 with whatever number the instance is. 0 represents the first instance, 1 represents the second instance, 2 represents the third instance, etc.).

2. If the bot is still running, press Ctrl + C to stop the bot.

3. Run exit to close the tmux instance.

4. Follow the steps above for the case where there is no instance of the bot running.

The purpose of steps 1-3 is basically to stop the old bot program, then exit, then create a new tmux instance with the updated version of the bot (since we did git pull).

Make sure you only have 1 instance of the actual bot running at any given time, otherwise you will get weird behavior when Enoch responds to commands.

Adding new users to EC2

Follow these steps on the AWS Documentation. (This requires access to the AWS account.)