Wonderful! Just going to add some remarks / thoughts… we might call this the “Social Coding MVP” and when spinning up an app, it is a “social coding platform”.

Ideation --> Idea Management

• “Idea Management” appears to be a more common domain name.
• Federation between social coding instances:
  • Consider a solarpunk.community and a vidartists.social instance.
  • Ideas should be spread far and wide, ideally federate between instances.
  • A solarpunk “low-energy video editing” idea is interesting to vidartists, a “solar panel upcycle” idea is not.
  • There may be need for a Topic as a separate concept. It might be an as:Group on the wire.
  • Instances receive all Topics from across the fedi, then admin subscribes to interesting ones.
  • Only Ideas matching Subscribed Topics are tracked / stored in a particular instance.
• Federation across the broader fediverse:
  • From any federated app, e.g. Mastodon, a fedizen can Follow a Topic and then get all topical Ideas in their timeline.
  • This works somewhat similar to Gup.pe groups app.
  • If I follow “Video Editing” on vidartists, I will also get Ideas in that topic that were created on solarpunk.
  • I don’t know if de-doubling is handled if I subscribe to the topic on multiple instances.
• Licensing of ideas
  • Different instances may have different ideas on how Ideas and the comments to them are licensed.
  • The license that applies is determined by the instance that the Idea / Comment was created on.
  • If one replies from e.g. Mastodon, then the license of Idea is used. It should be indicated in the Topic Profile.
• We can create a diagram and derive our own vocabulary extension for our domain. Interesting prior work:
  • There’s an idea ontology specification to be inspired from.
  • Diagram can be simple with just balloons and arrows (taken from this Innovation Domain paper).
  • There’s another, rather complete ontology: Generic Idea and Innovation Management Ontology (Gi2MO)

Community Governance

• I’d split this into two separate parts / concepts: Community + Policies
• Both of these concepts have way broader applicability than our use case, and we can standardize on their definition.
  • For Community I am advocating for a “Community has no Boundary” paradigm (info is a bit dispersed on the forum).
  • For Policies I found some usable ontologies and commented further on (thread itself is beyond scope).

For a minimal Community vocabulary extension that facilitates having arbitrary ‘Roles’ I suggested modeling them as follows:

Project Management

• There is the DOAP Ontology to describe projects (also posted to forgefriends).
• I guess that the Project Management features here should be mostly informational.
  • Referencing repo’s, tools that may exist anywhere. Insight into any relevant project info.
  • Ensuring that privileges are properly guarded and to the interest of the community as a whole.