Indymedia reboot and epicyon codeing - hackathon

ok, this is great, to get a better sense of it’s reach.

Tell me if this is too far off-topic in this particular thread.
But I would still be interested in determining some method for scaling.
These would, at the very least, be “recommended/ sensible” defaults.


I believe that once a group of people (collaborating, or even just participating in the same space, digitally or physically) gets beyond a certain capacity, moderation, consensus and forward-moving discussion/action becomes near impossible (and maybe this is a good thing).

Consider any species population on the planet. Once a certain scale is met, it will self-divide, or if not in it’s nature, it will be kept to a healthy size by a predator (do not anthropomorphise the word predator).

Example

Let’s assume a maximum size for any functioning community to be 150 (I lean toward slightly less, but it’s a more round-ish number).

15,000 people choose to be involved within one IMC, and they do not wish to divide into several smaller (approx 67 IMC’s) - one option might be:

  • Divide the 15,000 into 100 “sub-IMC’s” (groups) of 150 members

    • each work with an equal proportion of the data flows coming in and going out from the IMC (blogs, reports, toots, etc…)
    • there is no division based on content
    • each group should be capable of handling all content types
  • Within each 150, have tight “guilds” ranging (default) from 3-12 members

    • for a particular sub-set of the data flows - maybe determined simply by a specific set of #hashtags
    • 3 minimum, required for consensus
    • 12 is already a risky maximum for being able to maintain reasonable consensus
  • Each “guild” shall likely be “specialised” in their expertise

    • multiple guilds may have the same specialty
      • sharing a proportion of the sub-set of data flows, or based on #hashtag, etc
    • consensus should be reached between related guilds
      • automatically propogated out when making decisions within the guilds’ “specialty”
      • before propagating out to the wider set of guilds - for IMC-related decisions
  • Further “guild-level” consensus may be implemented between groups for manageable “web”- (as opposed to hierarchical) decision making for the IMC at large.

  • Each of the 100 groups could similarly have a “web”-based decision making approach, in order to achieve consensus among the IMC in toto.

    • at this level, should consensus be difficult to reach, particularly repeatedly, this would be a strong sign to split
      • obviously the splits would ideally remain connected as “trusted peers” within the larger network of IMC’s.
  • Regarding consensus, there could be more “levels” between “guild” through to “group”, but kept to a minimum here for brevity.

    • sets of 3 “guilds” may have to first achieve consensus before
    • here we enter realms of more complication that require more thought, and would be more diverse in approach between different IMC’s

Of course, I accept that an IMC might choose not to follow this, but I believe we would be utterly remiss if we were not to encourage this.

If there is any level of agreement for this approach, I would happily discuss it further, as I feel it would greatly help in building a genuinely robust network, that may be resistant to the inevitable in-fighting and collapse of “oversized colonies”.