Problem: Trustroots branding is all over the page

[mariha]

If a new community was going to reuse Trustroots codebase, we have to make it feel like it's a space dedicated for that community, not Trustroots. Right now the page is fixed with Trustroots logo, name, colors and others.

Things to change (feel free to edit the issue and add more if something is missing):

• Configurable branding (mandatory):
  • [x] name instead of Trustroots - #44 #57
  • [x] logo - #44
  • [ ] colors: main color and dots on the map
  • [ ] config file with sample values - placeholders to be replaced with community specific values by each instance
• To be removed or replaced with config properties:
  • [x] contact information: support, social media, ... #44 #57
  • [ ] Trustroots organization: foundation, team, ...
  • [x] How it works? page - screenshots, manifesto and the whole page #44
  • [x] Rules page #71
  • [ ] emails - delegated to #46
• Non-core functionalities, to be hidden behind feature toggles: #17 #57
  • [x] circles #54
  • [x] meetups #48
  • [ ] ? friends
  • [ ] ? experiences
  • [ ] ? maybe messaging (other means of reaching out)

• [ ] Guidelines what is needed to setup an instance

  • Double check before closing the issue:
  • [ ] website
  • [ ] mobile app
  • [ ] ? whole codebase for unexpected Trustroots references
  • [ ] non-mandatory features are behind configurable toggles, tested on and off
  • [ ] config properties are defined, self-documented and tested for mandatory/optional-default values

Potential solution: create global resources file where branding and other configuration can be defined and reused throughout the codebase.

[lennartvanlaake]

Love the idea of abstracting away the branding. Maybe even nice to be able to put the branding in a database, so admins can dynamically change (parts of) the appearance of the platform?

[mariha]

As for an intro to C4, our process: basically it's up to the implementor to choose a solution to the problem that they like most. The role of maintainers (currently @OpenHospitalityNetwork/maintainers) is to approve any valid solution. We are all learning how it is going to work though... and we may still need to learn to state problems accurately ;). Either way I think it's very good to have a discussion of potential solutions, so thanks for starting it! after that the choice is up to you (or whoever is going to implement it).

Having that said, I wouldn't expect this data to be changed very often, once initially set I'd expect it to stay like this forever. So static config data seems enough for this, especially to start with. Still it allows the update, if needed.

Some things to consider:

• is there some other config data that we want to be able to dynamically reload at runtime? to keep it cohesive it may make sense to have all settings defined in one way: either in static config file or in a database.

• who and how is going to read and modify the data? If config is human-readable and editable, no special tools or knowledge is needed. For this yml files seems good to me, there might to libraries that reload config file every time it changes allowing the app to update settings at runtime.

• config data already existing in the codebase and how it is updated

[weex]

@mariha Was this handled by @chagai95's recent PR or should we keep it open until logo and colors are addressed?

[lennartvanlaake]

For me the larger reason behind doing this is that we can have one codebase with multiple instances, each having their own branding. To get to that point we still need quite a lot things to happen:

• everything a new community might want to change in terms of text or branding should not be in the (main) repo
• a mechanism should exist to inject new static text and branding in a way that allows pulling updates from the (main) repo to one of the community-specific instances
• all features (such as circles) that are not relevant to all communities should be toggle-able

If we haven't properly addressed these issues and start hard-coding federated/bike touring stuff in the repo, we won't be able to propragate changes and fixes between instances, which would make maintainance of multiple instances a major pain.

In terms of the C4 process, I would say it gives a bit too much power to a single developer to say that any implementation of fixing these problems would be fine. My preference would to create one issue to research all the things to be done for this to work, and then create separate "pull-request sized" issues for each unit of work that needs to be done to reach that goal.

[mariha]

I agree with the reasoning @lennartvanlaake wrote, gonna update the issue where it says what is and what is not in the scope.

@weex

should we keep it open until logo and colors are addressed?

I'd say if it's all easily configurable it would be done, whatever is used as placeholders. Specific logo and color, and in general all values for the config for that new community can be done separately.

For the process, I am moving the discussion over here: #74

(it may not make sense, I was writing a little bit in hurry)

[lennartvanlaake]

I am wondering what you think of the code base sync issue. Would you say that it is necessary to do, but part of a different ticket, or are you not concerned about that issue?

If you want to solve this in the current issue, so that you won't get merge conflicts when a different community is pulling in an update, I'd say we'll need lots more work done then just changing the color and icon.

[weex]

• everything a new community might want to change in terms of text or branding should not be in the (main) repo
• a mechanism should exist to inject new static text and branding in a way that allows pulling updates from the (main) repo to one of the community-specific instances

Feel free to correct me but I think what you mean by these is that the configuration should not be overwritten by a git pull. Often this is done by storing such data in db or in a (possibly generated) config file that is .gitignored.

• all features (such as circles) that are not relevant to all communities should be toggle-able

This would be good to add in a design philosophy doc. Optionality can be accomplished in many ways like checkboxes, plugins, config flags which are to me all great because the software can be made to work for many different communities.

hard-coding federated/bike touring stuff in the repo

I'd merge this and create an issue or PR to fix it. I don't think any of us wants to hard code that which isn't universal.

I agree that merged PRs can introduce problems and C4 basically 1) expects that and 2) expects that the community around the software addresses those problems as they come. So yes, a lot of power for one developer to change the code, which is quickly and easily corrected by others. The bias is toward progress and inclusion helping to grow a community out of which emerges the software.

I am wondering what you think of the code base sync issue. Would you say that it is necessary to do, but part of a different ticket, or are you not concerned about that issue?

I didn't catch where there was something new and hard-coded. If you see that, yes definitely make a new issue.

[lennartvanlaake]

@weex I think there is quite a bit to talk about on all of this, so I opened a Discussion here: https://github.com/OpenHospitalityNetwork/fedi-trustroots/discussions/76.

[mariha]

I updated the issue with more granular scope decomposition. I added also references which PRs change what so that we are able to find relevant changes more easily.