User:Eerik Wissenz/Proposed organic architecture

Architecture

OSE.org is on track to become so big as to be either essentially unmanageable or unable to go beyond a certain point in complexity because of a lack of management resources.

The solution to this problem in my view is to move towards a Spontaneous Organic Content Creation Model (i.e. the myspace model). Instead of managers having to decide who contributes to what, where their contributions go, what access they have, etc. another approach is to give everyone basic access to post (basically give them a blog), and let anyone post anything (turning active management into passive oversight in case of abuse). This solves two basic tasks:

1. No longer need to discuss with potential collaborators to judge whether it's worth the time or what they can do (anyone can just start blogging their thoughts into OSE, and if they make sense they'll make attention for themselves). As in, there's no investment in time to enter someone into the project.
2. Create a huge community and content flow.

The OSE project, as it exists now, would then be superimposed on this blog-farm. We can imagine all content entering the same way (a post of someone's blog) but able to be boosted to another higher level by the management, and so basically 4 levels:

Level One: just a thought

If someone posts something largely irrelevant to the tasks at hand, but perhaps interesting to someone, their post would simply appear on a "latest post" list for a time, and later could only be found by back-tracking, search engine, or going to their profile and seeing all their posts.

Level Two: Relevant

However, if someone posts something relevant, then the managers need only associate the appropriate key words to the post. The post will then appear in a list of latest posts, associated with the CEB for instance. (One bonus of this model model is that a single post can be associated with multiple subjects, so how the Solar Concentrator integrates with the Steam Engine can have 2 key words and appear in both places). Level two, though relevant to OSE, is still transient (development chatter) content, just can now be more easily created and found. People can also be left to associate level two key words themselves, and have this ability taken away if they abuse it (or their account deleted all-together).

Level Three: Official

When someone posts someone important, then the article can simply be moved from their personal blog folder to the official folder of the subject, and integrated into the "official content" (if they aren't the admin of the section and so couldn't just post it there to begin with). For instance, if I post "lesson 3 of solar concentration" then it can be moved to the "solar tutorial folder" which is found in the solar folder. So this goes for planned content, but also spontaneous content that is such high quality it can integrate into the official content.

Level Four: Non-Public

For the internal non-public discussions, whenever they are needed, they can be made within the same system. For instance, though everyone has access to their own folder, admins can have access to other folders that concern them, and discussion, make drafts, etc. can be done in these private folders. However, if these private discussions are in the system, when the discussion has passed, then it can be simply moved from the private site to the public site by simply changing folders so the history of OSE is preserved and made public.

Advantages

The basic advantages of this system are 3 fold.

1. Self organization

As much as is possible, the content can self organize. People make posts and simply associate the key words the post is about. But beyond that, the members of the community can also organize the content. For instance, person A may post a Level 1 content, just an idea they had, and person B may pick up on that idea and post a related thoughts; things could go on like this for a bit on Level 1; when the thought is mature, someone might then bring it to level two (referencing also the previous posts about the subject), and after further development and work the idea may be brought into the official content. All this can happen without any particular managerial intention to do so, just oversight.

2. A huge amount of content

The second advantage is that this system can leverage the huge amount of content already created as well as invite an even bigger amount of content. More content means more search engine results, more visitors, more people discovering OSE.

3. Everyone has an opportunity

The third advantage is that it gives everyone the opportunity to contribute. No contribution becomes so small that it does not have a place. This also creates a sense of community.

For instance, a true fan may simply want to blog about their experiences spreading and talking about the GVCS. (Also of note, is that content can be "post-organized". For instance people may spontaneously start a new type of content that no manager foresaw existing; if such content becomes popular enough, new section in the site can made dedicated to it and people can then associate the new key word to their existing content. So this also encourages people to make entirely new projects.)

4. Super simple

Another big boost in this sort of system is that the people that create content don't have to worry about organizing it, all they have to do is create articles and publish them, the whole navigation is then put together automatically. So people who aren't computer savvy have things simplified as far as is possible, so that creating content is essentially the same difficulty as creating an email. They also only have to learn a single system to interact with the project.

5. Reduce management

For the 4 reasons above, management is significantly reduced. For instance, long email discussions before someone enters into the project is no longer necessary, new people can simply start blogging and when they've posted everything they want to do, can give a small shout out to an administrator to check out their material for further council, support, team-work etc. This leverages "starter content" and gets rid of the situation of investing a significant amount of time discussing with someone who in the end does not contribute.

Another reduction of management is the reduction of services that need to be manged, by placing all content in the same system, the tasks of maintaining multiple systems is reduced as well as the task of transferring content from one system to another. Once a piece of content is in the system it can get to where it needs to be by simply associating key words or moving folders.

Disadvantage

The main disadvantage to this approach is that the system has to be created to be able to do everything OSE needs to do. So there is an investment in time to create the system. However, once created it can evolve, improve and augment indefinitely largely on it's own.

Conversely, the main advantage of using free pre-built services is that their fast to start, but the disadvantage is in the long term it becomes just as hard to make a meta system to integrate them all as it would be to simply create one single integrated system. Also, more services mean more maintenance, more things to go wrong, and in the case of free services hosted elsewhere generally the data base can't be taken, so all the content can't be leveraged in new ways.

Notes on Spip Documentations

Sorry, I miss-stated about the Spip Documentation.

All the documentation for developing and using Spip is in English. I meant to say there was little secondary documentation, such as blogs discussing the differences, advantages etc. so if you search opinions about Spip in English you don't really find anything. Though there are many English webmasters using Spip and discussing in the Spip forums, so English support would be there.

Yes, Vann's view of Spip as below Drupal or Wordpress but above Zend, Ruby, Django is correct. Spip is in the category of a content framework. The purpose is Spip is 3 fold 1. Provide the webmaster with a base of tools their probably going to need 2. Not impose any specific design architecture 3. Fluidly transition to integrating custom code

So, in terms of basic tools the main ones are organizing the content in a database (folders, sub-folders, providing access, permissions etc), and the Spip loop syntax which is just a short hand for many PHP scripts you're probably going to need for a content oriented site.

In terms of fluidly transitioning, what this means is that the Loop syntax is carefully made so that you can augment it with custom PHP and regular expressions or other code if you don't quite get to where you want. The advantage to this is that as the site evolves and content becomes more complex you can simply refine the existing Spip loops with PHP and regular expressions, rather than restart and code something completely parallel.

Whether Spip is chosen or not, the framework approach I think is the correct way to go, since they're the most flexible. A non-coder oriented CMS, like Drubal, Joomla or Wordpress, are great if you don't want to code, however, what happens if you can code is that modifying complex configurable plugins becomes more work (and a lot riskier) than simply writing exactly the script you want from scratch. This latter approach is what a frame work is there to simply facilitate (for instance providing a back-end for interacting with the database, that has been tried and tested security wise, so you don't have to code one yourself).

Wiki vs Framework

Obviously a wiki is also meant for organic content creation. The differences would be:

1. One of feel, people would feel they're "blogging" rather than contributing to a wiki, and in my opinion would be more comfortable to start out, and more comfortable blogging whatever their thoughts are rather than auto-criticizing before even posting (and so never posting anything).
2. The content can be made to flow in a way far more relevant. A wiki is designed to snippets of independent subjects and is hard to break out of this model. For development, there's not a lot of independent posts but rather a huge volume of posts around a specific subject;so in a framework, all the content can flow around the subjects (each tech could have a sort of control room control room, with all the latest posts, comments etc.) Also, meta key-words such as "important", "to-do" etc. can also be added to posts to further organize them. Likewise, in a framework you can have "key-word groups" so that a page can associated with a component of the CEB for instance, and automatically appear in the latest on the CEB, but appear only with other posts on that component when one "zoom's" in on that component (i.e. each component would have it's own "control room", and indeed the whole project could have a "control room" ... maybe "situation room" is better); so it becomes easy to follow the whole project, a specific technology, or a sub component by zooming in and out of the content flow.
3. In a framework the design is put into the content and not the content into the design, so things would in general be a lot sexier and could easily be augmented indefinitely.
4. Lastly, in a framework all the services currently orbiting around the wiki could be coded into the same system, which reduces management considerably and allows far greater possibilities of leveraging content.

Now, a wiki is open source so in theory could be augmented to act as a framework, but in my experience it's a lot easier to use the tool designed for what you want to do rather than adapt another tool.

Response?

I hope I'm not stubbing your wiki toes! I'm straddling that exact hurdle, at the moment, and you're outlining my dream interface. :) I like the way you think. Labels are far more flexible than folders, assigning labels a priority scale creates those lovely layers of relevance you mentioned, and label hierarchies allow that 'zoom' that'll become so critical as we do more detailed prototypes and input/output accounting. It sounds like the framework could easily morph into an attached 'library' to OSE and Factor e Farm, affiliated with it, and maintained by the distant crowd, instead of Marcin; perhaps, that could be the initial step? ...As a self-organizing clearing house for OS hardware and project collaboration of all stripes, a blog/discussion board for personal connections (so important, for maintaining motivation!), and a more private, technical layer devoted to Marcin's 50 tools, and Factor e Farm activities, in particular. We've got a blog, a forum, and a wiki, currently - they'd all collapse into one archive. One point that might be relevant: when you diagram flow, you don't just label the objects - you label their connections, too. The nature of their relationship to the topic is what defines 'Moderator Notices', 'Final Drafts', 'Resource Links', 'Tangents & Points of Interest', etc., and it's unlikely these will be searched for as a group - you don't want to search for every resource link to every topic. Just filter within that topic, by 'Resources'. The other side of this: we forget a lot. A single index is invaluable for the task of orienting yourself within the context, and accurately directing your energy. I'd love to have a 'Complete OSE Index' that I could filter by object label, as well as the labels of its posts' relationships, and allow full zoom & cross-linkages along all paths. I dunno how to do that fancy computer stuff, but if it were here, I'd be happy to help organize the data on it. :) (I addressed a few things in this post: opinions, summary, concerns, options, offers... how would we tag each of these aspects, separately? 'Color-code' text according to its relationship labels, for folks to self-moderate? We'd have to keep the number of relationship labels low, or it'd become unwieldy. Other options? <- and this is a 'request' type, as opposed to an 'info question' like "who is in charge of CADing this design?" ... searching for all the 'current requests' would be a quick way to sort tasks.)

- Anthony, 'the little black bird' :)