Omni Commons - User contributions [en]

Omnicommons.org

2015-04-24T22:10:59Z

Dhorn: forgot to paste in the whole thing, whoops

Omnicommons.org ([https://Omnicommons.org link]) is the main website for the Omni Commons.

== Development ==

The best way to add changes to the website is to fork the main repository ([https://github.com/omnicommons/omnicommons.org github.com/omnicommons/omnicommons.org]) then clone your fork to your local machine and test your changes locally before committing a pull request.

The following text will go over how to get the code on to your local machine and how to configure the machine to display the website, read on!

=== Fork, Clone, and Configure the Upstream ===

We assume you already know how to fork a github.com repository, if not please check out [https://help.github.com/articles/fork-a-repo/ github’s article on repo forking]

==== Clone the Repo ====

Once you have the repository forked you’ll want to clone it to your development machine using the clone command.

Here’s the command that github user dhornbein used:

<code>git clone git@github.com:dhornbein/omnicommons.org.git</code>

'''Note:''' This command will be different for you as <code>dhornbein</code> will be replaced by your github.com user name (or where ever you forked the repo)

==== Configure Remote Upstream ====

The “remote upstream” is a git remote repo that you pull from for the latest versions of the code. You will add the Omni Common’s omnicommons.org repository as the upstream remote location so you can perform <code>git pull upstream</code> to pull down any changes to the site since you forked it.

First we’ll add the upstream remote, you can copy and paste the line below:

<code>git remote add upstream git@github.com:omnicommons/omnicommons.org.git</code>

Now check that it worked by typing <code>git remote -v</code> to see all remote repos, it should look like this:

<pre>origin git@github.com:dhornbein/omnicommons.org.git (fetch)
origin git@github.com:dhornbein/omnicommons.org.git (push)
upstream git@github.com:omnicommons/omnicommons.org.git (fetch)
upstream git@github.com:omnicommons/omnicommons.org.git (push)</pre>
Basically this is saying that the '''origin''' of the files is at your (show as dhornbein’s) forked repo and the '''upstream''' destination is the Omni Common’s repo.

=== Setting up Server Side Includes on Localhost ===

The Omni Commons website uses Server Side Includes (SSI) to pull in head, nav, and footer html from the <code>/includes</code> folder. So we need to set up your local environment to handle this. Much of the following information is taken from [http://www.linuxtopia.org/HowToGuides/apache_ssi.html linuxtopia.org’s how to guide on apache ssi].

The SSI strings look like this:

<code></code>

Once SSI is enabled this line will be replaced by the content of <code>/includes/nav.html</code>. This allows us to edit the nav ''once'' and have those changes appear on all pages with the above snippet.

==== Enable mod_include ====

The first thing to do is ensure that your server has the mod_include module installed and enabled.

The following instructions were tested on an Mac OS X (10.9) machine but should work on any Linux machine as well.

First we will examine the Apache Config file <code>httpd.conf</code> typically located at:

<code>/etc/apache2/httpd.conf</code>

Make sure that the includes modual is present and active by searching for <code>mod_include</code> within the <code>httpd.conf</code> file, look for this line:

<code>LoadModule include_module libexec/apache2/mod_include.so</code>

Check that there isn’t a hash (#) in front of the above text (you’re text might differ slightly).

==== Turn on Includes ====

You’ll want to turn on the include option through your virtual host by adding:

<code>Options +Includes</code>

Here’s Drew’s vhost as an example:

<pre><Virtualhost *:80>
VirtualDocumentRoot "/Users/drew/www/%-2/"
ServerName vhosts.localhost
ServerAlias *.localhost
ErrorLog "/var/log/apache2/vhosts.localhost-error_log"
<Directory "/Users/drew/www/*">
Options Indexes FollowSymLinks +Includes
AllowOverride All
Order allow,deny
Allow from all
</Directory>
</Virtualhost></pre>
''Side Note: Drew is using a nifty trick to automagically add folders in <code>/Users/drew/www/</code> to their virtual host, you can read more about that on [http://www.glenscott.co.uk/blog/simple-development-hosts-on-mac/ Glen Scott’s blog post Simple Development Hosts on Mac]''

Pay attention to the line where <code>+Includes</code> has been added:

<code>Options Indexes FollowSymLinks +Includes</code>

Now we need to tell Apache to scan the proper files for includes. Typically, due to the extra server overhead, this is done only to files that are specified as having includes by using a special extension <code>.shtml</code> to indicate to the system that they should be scanned.

The OmniCommons website uses <code>.html</code> throughout, so we simply need to tell our local apache server to scan all <code>.html</code> files for includes.

Go back to your <code>httpd.conf</code> and find the line with <code>#AddOutputFilter INCLUDES .shtml</code> now add under that line:

<code>AddOutputFilter INCLUDES .html</code>

The hash (#) indicates that a line is commented out, because we want the config file to read our command we omit that hash. So this command is adding an output filter (<code>AddOutputFilter</code>) that applies Includes (<code>INCLUDES</code>) to all html files (<code>.html</code>).

You should now be able to visit your virtual host, in Drew’s case it is <code>omnicommons.localhost</code>.

'''Remember:''' The apache include will ''not'' run if you open the .html file directly in your browser, it must be served from the virtual host.

Omnicommons.org

2015-04-24T21:45:35Z

Dhorn: added information about how to edit the main website

User talk:Dhorn

2015-04-03T21:06:25Z

Dhorn: /* Things Drew Could Work on */ new section

== Things Drew Could Work on ==

I'll be here for the month of April (2015) and am making a list of things I could potentially do.

* Practicing the use of [[Change Up Meeting]]

Change Up Meeting

2015-04-03T21:01:36Z

Dhorn: added bulk of information about the Change Up Meeting

This page is meant to document a game called Change Up, or Change Up Meeting. The content here is adapted from [http://everett.agilelearningcenters.org/2015/03/19/alce-tools-change-up-meeting/ Drew Hornbein's blog post title Change Up Meeting]

Creating culture can be a difficult task. Lots of though and time goes into documents such as the [[Safer Space Policy]]. How, though, do we update our community agreements as the culture grows? When new and exciting opportunities and issues arise our culture needs to be able to adapt.

== Currently ==

Currently changes to community agreements are handled mostly though consensus processes. Let's consider an abstract example, a few people wish to bring a [[Hoobaldada]] into the space, there are some costs associated with housing the Hoobladada and while people are generally fine with it, the location is disputed. The Hoobaldada proposal is brought to a consensus meeting, it's location is discussed ad nauseum and the costs are broken down and also discussed quite a bit. Each location for the Hoobaldada is '''imagined''' by the group and the pro's and con's are considered '''abstractly'''. The aim, as you might know, of a consensus meeting is to come to an agreement and create a ''some what'' permanent decision and to '''end discussion around the proposal''', hopefully in a way that leaves everyone feeling ''okay'' about it.

So the proposal passes after a lot of discussion and time investment. We are left with a decision for where to put the Hoobaldada, it's not exactly where people ''really'' wanted it, but it's okay. As time goes by it's seen that it doesn't really work in it's current configuration but the idea of making another proposal isn't all that appealing and we are left with a Hoobaldada that isn't making people as happy as it could.

Let's consider another way, the Change Up Meeting.

== How it Works ==

The Change Up Meeting is a reoccurring gathering (weekly, monthly, etc.) where all invested members of the community meet and work on the [[Community Mastery Board]] (CMB). The CMB has four columns labeled:

* Awareness
* Implementation
* Practice
* Mastery

[[File:Change-up-cmb-columns.jpg|framed|center|Column names of the Community Mastery Board]]

Topics enter into the process as an '''awareness'''. Community members share something they are aware of. This could be a problem or an opportunity available to the community. At any time anyone can leave a sticky note on the awareness column of the CMB.

Each week (or month, etc.) in the Change Up Meeting items from the CMB are discussed as a group. As we reflect on each item in the awareness column the group attempts (if needed) to imagine a way to deal with the item and select one to try and move the note to '''implement'''. If we don’t have any ideas then the item stays in awareness.

Once a solution is implemented we try it out for the week or two. The items in the implement column are limited in number because we don’t want to be introducing too many new rules or procedures at once. Each week we reflect on how well each particular solution is working. Are people abiding by the new procedure? Is the community happy with it?

Rather than have a long processes driven meetings about the implemented solution where we voice concerns and attempt to codify a community agreement in one sitting we do rapid testing of our agreements. Over the course of the week new agreements are tested and community members can “vote with their feet” where if they like a particular agreement they can promote it during the implementation week, remind people that we are trying it out, and build support for it.

Once an agreement has been implemented we revisit it at each Change Up Meeting where we either:

* Demote it back to awareness if the implemented solution didn’t work
* Keep it implemented for another week to continue testing
* Change the implementation and try it again
* Promote it to practicingAgreements in the practicing column are both in practice and being practiced. Each week we quickly review all items in this column to determine if they need to be demoted because they aren’t working or if we have mastered them.

If an agreement has reached a point where it has passed a certain threshold defined by the community it can then be elevated to the '''mastery''' column.

This diagram illustrates how a single item might move through the process:

[[File:Change-up-cmb-process.jpg|frameless|center]]

Let's go back to the absurd example from above. Someone becomes aware that a [[Hoobaldada]] is available and they put a note under '''awareness''' on the Community Mastery Board. At the next Change Up Meeting someone suggests putting the Hoobaldada in the front entry way, some people aren't really into that idea but they are fine to try it out knowing that next Change Up Meeting it will be addressed if it isn't working. So the Hoobaldada topic is moved to the implemented column and a note is added about moving it to the entry way.

At the next Change Up Meeting it's obvious that some members of the community aren't happy with the Hoobaldada in the front entry way, they suggest moving it to the basement. It is agreed to give that a try and the process repeats. By the next meeting the community is feeling good about the placement and decides to move the topic to the '''practicing''' column. Now each week the topic will be briefly mentioned, if issues come up then further implementations can be experimented with. After a little more time the Hoobaldada feels quite at home in it's location and the group decides to move the topic to '''mastery'''.

== Mastery ==

The Hoobaldada example is dealing with a ''thing'' in the community. While this process could work very well with things it works really well with '''community behavior'''. As people become aware of issues the Change Up Meeting is a way to try, practice, then master behaviors to better the whole community. For instance one example of a practice already mastered by the Omni community is to abide by the [[Safer Space Policy]].

All the items in the Mastery column make a complete list of community agreements. By using the Community Mastery Board the community develops and makes explicit what how the community opperates. This gives a very clear picture to new comers what their expected behavior is.

The Change Up Meeting process gives all members of the community a clear means to ''change up'' the behavior of the whole community through a process that doesn't require lots of '''process''' as seen in the consensus process.

Change Up Meeting

2015-04-03T05:34:21Z

Dhorn: Just starting out a page about change up meeting

File:Change-up-cmb-process.jpg

2015-04-03T05:32:35Z

Dhorn: A typical Change Up Meeting process

A typical Change Up Meeting process

File:Change-up-cmb-columns.jpg

2015-04-03T05:30:44Z

Dhorn: The column headers for a Community Mastery Board

The column headers for a Community Mastery Board