In the current codebase, there are still quite a few places that assume the context of DEV, e.g. certain profile fields or integrations. Here is one example from my recent profile generalization work:
# app/controllers/stories_controller.rb return unless @user.employer_name.presence || @user.employer_url.presence
Many communities will not have an "Employer name" profile field as they'll be geared towards hobbies, not professional exchanges.
- Littering the codebase with conditionals. We already have presence checks around many of these attributes, but in the future, we can't even assume they'll be there at all. Sure, we can update the conditionals, but it's a lot of work and in some cases could lead to a lot of added complexity due to an increased number of possible code paths.
- Even if we make all these changes, we’d essentially be making DEV’s history part of Forem’s future. This is not great from either a maintenance perspective, nor does it help with attracting contributors, as this is the sort of complexity that makes some sense if you’re part of the core team and have the historical context, but is somewhat hard to relay to the external community.
- If we were to just remove this, DEV would loose existing functionality. I’m not sure how desirable that is.
- Should DEV receive any special treatment at all?
- If yes, for how long?
- If not, is it ok for DEV to lose features while we generalize the app?
- Does DEV need to run on Forem
master, or could it potentially run off a fork that tracks master, but re-adds certain legacy features?
- Feature set vs. complexity/maintainability. Are we willing to drop certain things DEV supported to have a more cohesive Forem code base?
- Specialized vs. generalized. DEV was a specialized community for coders. Is it conceivable to have an app that will allow Forem admins to specialize their communities to other domains to the same extent? What does that mean for the complexity of admin tools? Is there merit in a more "omakase" or "less is more" approach?
- Company vs. community. Increasing complexity may be detrimental to community contributions, but desirable from a company POV.
This got a bit longer than expected, curious to hear everyone's opinion.