^^

Topics are stored in the server's role list in the format Topic | <Topic.name>. This Topic | prefix has to be prepended (PREFIX + Topic.getName()) everywhere that mentorbot interacts with the server's role list. It would be better to create a new method, Topic.getRoleName(), that handles this within the model itself, so that the controller layer does not have to worry about this concatenation.

Instead of re-running $queue, there should be a $leave <topic> that kicks you out of that queue.

• Add these role checks to isAdmin()
• Grant view permissions to these roles when creating mentoring rooms

Frameworks like the Android app development system tend to store all user-facing text in a key-value store. This makes it easier to implement translations and to quickly update messages. @peterkos suggested a similar system: generate the $help embed and error messages from a static class to keep most/all of the user-facing text in one place.

Tasks

• Create a BotResponses static class that contains a static getter for each message. Look at authbot's BotRepsonses.java for reference.
• Replace all existing message strings and embed builders calls to BotResponses static getters

The feature was added, but we never actually tested it 😬

HashMap -> TreeMap?

Certain commands, such as $showqueue, contain information that should be kept somewhat private. Restricting sensitive commands like these to a specific channel would allow server administrators to ensure that the privacy of their users will not be violated.

Perhaps create a custom role that stores a channel ID (e.g. MentorChannel:<base64 channel ID>)? This allows us to keep on our trend of storing all persistent per-server data in the server's role list itself, thus not requiring a separate database solution.

Commands should be stored/read as lowercase for simplicity

A mere mentor should not wield such devastating power

Most user input is validated, but in several places, if invalid input is received, the command functions simply return without displaying an error message to the user. Users should instead receive a warning when they provide invalid input, format a command incorrectly, etc.

This is strongly related to #9, so we should probably resolve that issue first.

Allow users to add a message when entering the queue. This will show up in $showqueue and will allow mentors to prune the queue more easily (#21).

Things like Topic.PREFIX

We need this to be hosted permanently for Brickhack 7. @Madrugaur had good success hosting authbot on Heroku; we should be able to do the same for this project.

Current user flow (discussed at Jan 30 meeting):

• User runs $queue <topic>
• Mentor runs $ready <topic>
• <topic> text/voice channels are created in Mentoring category
• Channels are deleted after user and mentor leave voice channel

Issues with flow:

• "user and mentor leave voice channel" assume voice channel use, which isn't very accessibility-friendly
  • Ask deaf/HoH users to join and leave voice channel?
  • Mentor runs $finish command inside text channel to end interaction?

@peterkos suggested that users that call $help should not be able to see commands that they do not have permission to run. For example, a regular user should not see help info for $ready, and a mentor should not see help info for $maketopic.

I am currently working on documentation, and while trying to compile from the command line, the generated .jar file fails to run:

...\mentorbot>java -jar build\libs\mentorbot-1.0-SNAPSHOT.jar
no main manifest attribute, in build\libs\mentorbot-1.0-SNAPSHOT.jar

It appears that the main class isn't specified in the .jar file because jar.manifest.Class-Path isn't set in build.gradle (source).

ready() doesn't check to make sure there's someone in the queue before popping from the queue

Currently, only administrators are allowed to use mentor commands like $ready. However, this is insecure in production, especially considering the large number of (unvetted) mentors that could be participating in BrickHack. Checking for the existing topic roles instead of administrator status would alleviate this issue.

@peterkos's suggestion:

[It] might be cool to have separate categories of topics: a set for langs, a set for frameworks, a set for design help, a set for "how to build X" (where to start building backend, app, etc.)

This could be implemented by adding another layer to the tree structure:

Server
 |_ Category
    |_ Topic
        |_ LinkedList<Member> queue

Director -> Directors Offline
MLH -> Major League Hacking

I/O should not be inside the check method

$kick <topic> <mention>: Remove a user from a queue

Useful for moderation

BrickHack and other hackathon servers will likely be setup by people without intimate knowledge of this bot's inner workings. Proper documentation is needed to explain how to correctly setup these servers so that the bot may function effectively.

We should also take time to add internal (read: in the code) documentation, especially for things like the per-command methods.