Related to https://github.com/EddieJaoudeCommunity/EddieBot/pull/247 and #134
This actually came from another discord server who looked at https://github.com/kentcdodds/kcd-discord-bot but the issue is you get all the features if you want to fork this bot but only need one piece of it's functionality?
If bot had an enabledFeatures key, even better environment variables where you can simply enable features or even something as simple as an YAML/INI file if you really wish.
e.g. the .env.example would make you need to implicitly state you wish to enable functionality.
ENABLE_THIS_FEATURE=0
ENABLE_THIS_FEATURE=0
This makes forks of the bot for usage outside of the community server possible e.g. someone may only want the high value role feature.
If you would like to continue contributing to open source and would like to do it with an awesome inclusive community, you should join our Discord chat and our GitHub Organisation - we help and encourage each other to contribute to open source little and often 馃 . Any questions let us know.
@stemount this is a great idea 馃憤. Having feature flags could be very beneficial for the exact reason you said: someone may only want the high value role or reminders.
I agree this should be configurated in env variables, and then exposed as fields in the config.ts. Then each command/file that is responsible for a feature checks if that feature is enabled before continuing.
I hope this can also make it easier for people that don't want a DB setup (even if with docker this is easier). Maybe storing data on the DB can also be enabled/disabled like a feature flag, but what does everyone else think?
@stemount @BOLT04 great ideas 馃憤 . Yes lets do this 馃挭
@BOLT04 @eddiejaoude I definitely think the Firebase element of this actually is quite a blocker to novice programmers who we are supporting in our community.
It's quite "dump in the deep end" for somebody who has just got their head around Docker and docker-compose and also it is not necessary for all the functionality too.
Eddie is already on the money with #263
Are we all agreed that we should go with the "implicit enable features" thing?
As the GitHub workflows will allow us to deploy environment variables in the files - (when this thing is hosted somewhere - which is a totally different discussion) we can deploy with enable/disable features this way using GitOps as "policing" the production/dev bot with main and develop used respectively.
I think we should do this 馃憤 - if it is done with code config or envars, a re-run of the Action will still be required. So we should go with the simplest/best option.
agreed @stemount and @eddiejaoude 馃憤
@BOLT04 @eddiejaoude this issue needs the feedback from the community, maybe another video on eddiebot would be cool?
yeah good idea 馃憤
I am planning a live stream tomorrow to fix the config for AlexJS and we can talk about this too 馃憤
We could perhaps add a config-command(after setting it as server admin only), which enables toggling commands and features? (and more customisations, such as setting the self-assignable roles)
Something like that would extend EddieBot to be useful for other servers as well since currently it is primarily oriented with our community server.
Most helpful comment
@stemount this is a great idea 馃憤. Having feature flags could be very beneficial for the exact reason you said: someone may only want the
high valuerole or reminders.I agree this should be configurated in env variables, and then exposed as fields in the
config.ts. Then each command/file that is responsible for a feature checks if that feature is enabled before continuing.I hope this can also make it easier for people that don't want a DB setup (even if with docker this is easier). Maybe storing data on the DB can also be enabled/disabled like a feature flag, but what does everyone else think?