Suggestions are a way for the community to... give suggestions, as well as report problems, partnership applications, and more. It utilizes CarlBot.

Workflow

1. User makes a suggestion.

A user makes a suggestion and this will get posted to #suggestions. Suggestions are posted anonymously to allow us to recieve complaints without fear of repercussions. It will include up/downvote arrows with it and there isn't a way to turn those off. It does allow us to see how well the rest of the community does, or does not like the suggestion. We don't need to take those votes into consideration either.

We should encourage all users to use the suggestions function if there should be any changes to the server, or any commands that need to be ran by someone on the Student Council.

2. Consider or Deny.

We don't need to respond to everything straight away. Some things may need time for us to investigate, or wait for the community to voice their input. It may be used as a 'to do' list for us to get around to, eventually.

Consider

If the suggestion is good, but we need more time to consider or look into it, mark it as being considered. Doing this will:

• Send the suggesting user an update saying we are considering their suggestion.
• Make a post in #suggestions-log, marking that we are considering the suggestion.
• Update the original post in #suggestions marking that we are considering the suggestion.

Marking a suggestion as considered does not mean it cannot be denied later.

Use/example:

??consider <ID> <Reason>
??consider 15 nice idea, will look into it```

##### Deny
If the suggestion is abuse, not possible, a duplicate, or any other reason why we would not do the suggestion, mark it as denied. CarlBot will do the exact same things as above but 'deny' rather than 'consider'.

**Denying a suggestion does not permently close it.** It's status can be changed by anyone else on the Student Council at any time. Give a reasonable reason for why it has been denied. Addationally, marking a suggestion as denied does not mean it cannot be approved later.

Use/example:

??deny ??deny 21 not possible within discord right now```

3. Approve (or deny).

At this stage, after being considered, the idea should either be approved or denied.

Approved to us should mean that we will be going ahead the suggestion. When we get to it is a different matter though.

Denied at this stage should be more a case of where we can't, or is not feasable to do the suggestion after being considered.

Marking a suggestion as approved or denied will give the same effects as mentioned before.

If for some reason it is not possible or appropiate to do the suggestion within a reasonable bit of time, care should be taken as to what action here should be picked. Approving it should mean we will do it at some point while deny should mean we won't, or can't do it at all.

Use/example:

??approve <ID> <Reason>
??approve 18 great idea, we'll add that in!```

#### 4. Implemented.
At this stage, the suggestion should be considered completed and is now in effect in the server. The suggestion should also now be considered closed and there is no further action needed. Once again, making the suggestion will have the same effects as mentioned above.

It is still possible to deny the suggestion at this stage but it should only really be used if we are unable to complete it for more of a technial reason or limit that was really not possible to forsee in the previous stages. 

Use/example:

??implemented ??implemented 6 now in place, check #Example```

Overview.

This page is assuming that the suggestion is more of a complex one, taking up a bit of time to work out how to complete, or needs Council input before we can go ahead with it. It is aimed at keeping being transparant, showing that we are working on their suggestion and providing better management of suggestions to make "I forgot" a thing of the past.

With this in mind, the overview of this type of sucessful suggestion would look like this: Suggestion -> Considered -> Approved -> Implemented.

Minor suggestions.

Some suggestions may be so minor that having the entire above process will seem like overkill bureaucracy. To prevent this (again, for really minor suggestions that need no other Council member's input), the process below should be followed:

• The user should still make the suggestion. (For accountability, logging, archiving and transparancy)
• The change should be completed and marked as implemented.

This process could also be used if the reviewing Council member is not able to resolve the suggestion (i.e, they are at work) and could be a siginal to let other Council members know to complete it, or to mark that it will be completed once the Council member is able to. If that is the case, the below process should be followed:

• The user should still make the suggestion. (For accountability, logging, archiving and transparancy)
• The suggestion is marked as approved.
• The change should be completed and marked as implemented.