Context
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.
Why is this a problem?
- 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.
Open questions
- 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?
Discussion points re potential tradeoffs
- 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.
Top comments (5)
IMO we should be open to dropping features and reducing complexity where we can, especially if we're introducing more configuration-based complexity.
Certain DEV-centric features have merit in that the more technical communities may be more interested in stretching the boundaries than your average community, so the subset of programmer-oriented communities may want to share in features that allow for extensibility or whatnot. And there may also be some features which could be specialized for more employment-centric communities, and that's also a subset perhaps worth paying attention to as a group that might need some special consideration.
I think we should try and reduce complexity wherever we can, but some features will be worth keeping for DEV and every other programmer community or DEV and every other professional community, and we should think about those situations.
I'm totally seeing a vision for a repository of site templates here!
This sounds intriguing, could you explain a bit more what you envision here?
This is a massively interesting subject. I remember at the backend of last year, Inwas figuring out how best to ask for other details during on boarding rather than the Dev specific options. I just decided to raise an issue for generalisation (like I do for everything!) then just changed the html labels at onboarding and profile view, as I knew that eventually a more dynamic solution would arrive (I can see it coming in the commits 😍).
I think you are spot on though around making admin overly complex if there are too many options available for forem owners that aren’t overly tech savy.
Maybe the same approach Shopify have would be worth exploring? Base level customisation then an advanced level that allows you to change lots of different aesthetics but everyone knows you need to know about of web dev to do it. Maybe that would kick start the idea of having a group of Forem experts than can consult and help where needed 🤓
Thanks for the input, Lee! Shopify is a good example of how this can be approached. I'm still ordering my thoughts on the topic, but what I really want in the long run is making easy things as straight-forward as possible, while making complex things still possible.