v13: add info about communities

[carlinmack]

❤️ Thank you for your contribution!

Description

Please describe briefly your pull request.

Checklist

Ticks in all boxes and 🟢 on all GitHub actions status checks are required to merge:

• I'm aware of the code of conduct.
• I've created logical separate commits and followed the commit message format.
• I've targeted the master branch.
• If this documentation change impacts the current release of InvenioRDM, I will backport it to the production branch following approval or indicate to a maintainer that it should be backported.

Reminder

By using GitHub, you have already agreed to the GitHub’s Terms of Service including that:

1. You license your contribution under the same terms as the current repository’s license.
2. You agree that you have the right to license your contribution under the current repository’s license.

[fenekku]

Thanks! Since kind of dependent/related to #795, probably best to get that one in first.

[fenekku]

What is the feature name we want to converge on: "Branded communities" per #795 or "Themed communities"?

Once the other PR is merged, we should add a link to its relevant page(s).

[carlinmack]

not sure, ping: @ntarocco @slint

[slint]

Not decided yet tbh, so something we can discuss here.

"Themed Communities"

• Pros
  • Matches how we refer to the feature in code
  • Is "technically" more correct
  • Doesn't sound commercial or marketing-heavy
• Cons
  • A bit ambiguous, we also have a "Theming" section
  • Too "basic"? Kind of trivializes what you can do with it

"Branded Communities"

• Pros
  • Has a bit more "gravitas" as a term, i.e. you can imprint some identity to a community by "branding" it
• Cons
  • Sounds marketing-focused
  • Maybe a bit "scary" as to what the implications are (which are not that big, you just add some colors, and possibly override templating)

---

Personally, I prefer "Themed communities". It's a more advanced feature (you need to know about color codes and potentially Jinja templates), and instance managers/sysadmins would probably "get it" more easily.

[fenekku]

Yeah, eh 🤔 ? Put like that, "themed communities" sounds a little better. I even see it as a pro that it can echo the "theming" notion since it's essentially what we are doing with that feature, but at a community level. Although I am perhaps thinking more of this theme section. For what it's worth I've asked colleagues (no response yet though).

[fenekku]

Ok some other recommendations have trickled in from colleagues:

• Bespoke communities (admitted to be too highfalutin by suggester)
• Customized communities
• Tailored communities (a couple liked this one)

[ntarocco]

@fenekku thanks for the feedback, does this mean that we exclude "Themed"? I kind of like the simplicity of "Themed communities", on top of what all of you already described above.
"Bespoke" sounds very commercial to me :) Lately it is used by many companies advertising their products.
And Customized/Tailored feel a bit too generic, while "Themed" is immediately conveying the idea that some UI/colors/logo can be changed.

[fenekku]

I think "Themed" as well is the best in the end. (People found it fine too) With the explanation by Alex and the echo to the theme section I mentioned, it'd go for "Themed Communities".

[fenekku]

Suggested change

	Currently communities can only have one level of heirarchy (i.e., no grand-child communities) and communities can only have one parent community. The former restriction would be more easily overridden in your instance if required.
	Currently communities can only have one level of hierarchy (i.e., no grand-child communities) and communities can only have one parent community. The former restriction would be more easily overridden in your instance if required.

Also "would be more easily overridden" as in "it can easily be overridden in your instance"? Or, in the future we will make it overridable on a per instance basis? If former, probably best to word it as such.

[carlinmack]

I think it is "easily overridden" but need confirmation from @slint

[slint]

Via the programmatic API, one can infinitely nest communities; however, it has been decided that we don't want to officially support this, as it greatly complicates permissions (for both developers and end-users to understand).

Right now, we have the following building blocks for nesting content:

• Communities
  • Sub-communities
    • Collections Trees
      • Collections (at this point infinitely nestable actually, but just for organizing content browsing/discovery, and not access/permissions)

So I wouldn't mention anything about overriding here.

[fenekku]

So something like:

Option 1: no mention of overriding at all

"Currently communities can only have one level of hierarchy (i.e., no grand-child communities) and communities can only have one parent community.

OR

Option 2: just reword the 'more easily overridden part'

"Currently communities can only have one level of hierarchy (i.e., no grand-child communities) and communities can only have one parent community. The former restriction can be overridden in your instance if required."

OR

Option 3: explain the situation

Currently communities can only have one level of hierarchy (i.e., no grand-child communities) and communities can only have one parent community. The former restriction can be overridden via the programmatic API in your instance, but it has been decided to not officially support this in stock InvenioRDM as it greatly complicates permissions for end-users and implementers.

`

[ntarocco]

Removed, I also think that it is only creating confusion.

[fenekku]

Just last clarification on blurb, but otherwise all good to merge.