One of the things that I hear pretty frequently from people who first walk through the doors of Mars Hill is that they’re not really sure how they’re supposed to get connected. They might have a desire to serve on a particular team or join a community group, but they’re not sure who to talk to. And with how quickly ministries grow and change, it’s tough to keep track of that information in any sort of centrally managed repository (we’re long past the days where a spreadsheet, even online, could be accurate).

Of course, the ideal scenario would be to give the various info desks and community group desks all the information they need to be able to connect those dots for the newcomer standing in front of them at the desk. So why not build an environment where that can take place?

As I mentioned in the design principle discussion, Administration at the Edge and Content Finds its Target are key principles for The City. In this scenario then, The City would be home to all the Service Groups at Mars Hill; it would be a place for ministry team leads to surface their needs (”we need two more greeter leads”, “we need one more for the beverage ministry”, that’s the Administration at the Edge piece) and for the helpful people that serve on Sundays to connect the interested volunteer to the right ministry (Content Finds its Target, ie. no dropped communications).

The experience for the Info Desk volunteer would change to have a prioritized list of serving needs that they could use in their dialog with the potential volunteer to help match them to the right area of service. Likewise, the experience for the potential volunteer changes to a personal interaction aimed at connecting them into their area of gifting, and then allowing The City to carry the administrative overhead of making sure that they get a timely response from the service lead. No email lists, out of date spreadsheets, or massive central effort to keep up to date with all the happenings…rather, every info desk would be a portal to the needs of every campus.

This same pairing system would be used to help people find a community group to participate in. The community group desk would have The City at their disposal to look for a group that matches the physical locale of the interested attender and, with a click of the proverbial button, forge a digital bond between the community group leader and the potential attender (emailing confirmation as appropriate). With the approval of the group leader, directions could be sent, along with their own “welcome to our group” message, without having to surface phone numbers or addresses in any way.

What’s the goal? At the end of the day we want to enable everyone to know what is the next step in their walk with Jesus. If it’s getting connected as a Member, then it should be trivial to find out how the Membership process works and to kick it off without having to spend time researching. If it’s getting involved in a Community Group, then they should be likewise drawn into the community through the “neighborhood” from my last posting, as well as a highly equipped community group desk system that plugs them into community without barriers getting in the way.

So in this way, The City is designed to be developmental.

A few weeks ago Anthony setup http://vintagejesus.net. I was going to setup yet another deployment bash script on the server, but not all of our applications are deployed with a bash script. I stepped back and decided it was time to bring some order to the chaos of our current deployment strategy. Currently I use a lot of ‘organic’ bash scripts that deploy off of trunk, something I’ve never been a fan of. Mark enlightened me to use tagging to deploy apps. We use Capistrano to deploy some rails apps, so I figured I would set it up to deploy using tags. I was surprised I couldn’t find a plugin that I liked so I set off on building my own recipe.

The basic idea was that I wanted to run something like this:

cap deploy

The script should prompt for a tag, and if none is given prompt for a
tag name to apply to trunk and then deploy from the new tag.

As a bonus it makes rolling back a revision pretty easy. You can just select the previous tag, or use the built in:

cap deploy:rollback

To do this in Capistrano I created a set_tag recipe that lists the
recent tags and prompts to use one of them or create a new tag from
trunk. This updates the base_repository variable. I also had to
overwrite the default update_code action to call set_tag. (You may want to copy and paste it out since the formating gets a little hairy)

require 'rexml/document' #gem install rexml
set :application, "yourappname"
set :base_repository, "http://your.repository/#{application}"
set :repository, "#{base_repository}/trunk" # default, but is overwritten by set_tag

role :app, "some.prod.server", :primary => true
set :deploy_to, "/some/server/path"
set :use_sudo, false
namespace :deploy do
  task :set_tag do
    # get the release path
    depend :local,:command,"svn"

    show_recent_tags("#{base_repository}/tags")
    tag = ::Capistrano::CLI.ui.ask("which tag (blank for trunk): ")
    if tag == ""
      new_tag = ::Capistrano::CLI.ui.ask("deploy from trunk, but you have to give it a tag: ")
      raise Capistrano::Error, "have to tag a new release" if new_tag == ""
      #raise error if there are invalid characters

      raise Capistrano::Error, "invalid characters in tag" if new_tag =~ /[|]|\?|:|\/|\*|\"|\'||\||(\s)/
      cmd = "svn copy quiet message \"cap tagged release\" #{base_repository}/trunk #{base_repository}/tags/#{new_tag}"
      puts  "  * locally executing \"#{cmd}\""
      system cmd
      tag = new_tag
    end

    set :repository, "#{base_repository}/tags/#{tag}"
    puts "repository: #{repository}"
  end
  # Overwrite update_code task to add call to set_tag
  task :update_code, :except => { :no_release => true } do

    set_tag
    on_rollback { run "rm -rf #{release_path}; true" }
    strategy.deploy!
    finalize_update
  end

  def show_recent_tags(repo)

    hsh = Hash.new
    cmd = "svn ls --xml #{repo}"
    puts " >> Listing tags: "
    pipe = IO.popen cmd
    result = pipe.read

    pipe.close
    entries = REXML::Document.new(result).root.elements['list']
    entries.elements.each do |e|
      # set hash key to release id and value to: name by: commit.author
      hsh[e.elements['commit'].attribute('revision').to_s] = e.elements['name'].text + " \tby: " + e.elements['commit'].elements['author'].text
    end

    sorted_arr = hsh.sort {|a,b| a[0].to_i <=> b[0].to_i}
    if sorted_arr.size > 5
      sorted_arr.to_a[-5, 5].each {|t| puts "#{t[1]} \trev: #{t[0]} "}
    else
      sorted_arr.to_a.each {|t| puts "#{t[1]} \trev: #{t[0]} "}

    end
  end
end

Lets take a look at it in action:

cap deploy
>> Listing tags:
cap_test_0.0    by: sfaxon      rev:163

cap_test_0.1    by: sfaxon      rev: 167
which tag (blank for trunk): [type a tag listed above or hit return]

by just pressing return it asks:

deploying from trunk, but you have to give it a tag: [cap_test_0.2]

Next time I’ll show how we took this and applied it to other applications.

Update: direct link to the code above.

Over the last couple of days, Anthony and I have been kicking around the idea of ‘neighborhoods’. Social networks are replete with friendship based networks, and while I love the wonderful friends that I’ve been blessed with, they mostly know Jesus…so who’s my mission field? Stated another way, how can I meet new people that I can share the love of Christ with and invite into community?

This is where ‘neighborhoods’ come in.

Simply, your neighborhood is everyone that lives near you. Pretty basic eh? So why is this a cool concept? Let’s look at a concrete yet fictional example.

John is a community group leader in Ballard; he hosts his group just a little down the road from the public library off Market. He’s got a relatively new group with just five folks in regular attendance. He invites people to his group regularly, but they live all over the place! Ballard draws people from all over Seattle (and beyond), and finding the right people has been tough.

Jim is new to Mars Hill. He attended his first service, stopped by The City kiosk afterwards, and signed up to be “connected”, whatever that means. The volunteer that helped him was nice enough, but Jim doesn’t know what he’s supposed to do next. He lives near the old firehouse on Market, in fact, he works as a Brazilian Jiu-Jitsu coach at the studio there. If only John knew Jim was in his backyard…

This is where the ‘neighborhood’ thing I checked into the code this morning comes into play. John would see in The City that a new guy showed up in his neighborhood (without having to dig for it), maybe The City would even say, “hey, you’re the closest community group!” and John could reach out to Jim with a couple of clicks.

A similar scenario could be played out with a business network downtown…ever wonder who works in your building that goes to Mars Hill? Could be cool to have a lunch group once a week, talk about your life in Christ as you work at the Columbia Tower.

That’s the idea.

From time to time here at Mars Hill Church we receive emails with questions about the work that we do, who does it, what we use to do it and how the magic happens. For the second installment lets look at the website that kicked off the current sermon series, askanything.marshillchurch.org

Q. I’d love to get some background on how you developed the Ask Anything app - a very nice app, by the way. Was it all custom?

A. The short answer is “yes it was custom, thanks”.

The big idea was taken from the letter to the Corinthians, wherein Paul uses his letter to answer some popular questions from the church body in Corinth. We wanted to take a few months to collect questions and then take a one Sunday each to preach and answer the top 9 questions.

Development and design was an all done in-house here where we knew generally what we wanted out of it, though we also let the needs evolve as we developed it, and we could get things going quickly and adapt as need, so it ended up being coding in Ruby on Rails.

We looked into some more off the self type solutions, such as ShouldDoThis from the great Robot Co-op guys here in Seattle, but they often did not offer us enough control over the presentation nor the content posted by users, and any kind of phased approach. Though we wanted it to remain as open and as organic as possible, knowing we were opening this up to the world, we planned to need some level of control over things such as vulgarity, personal attacks and completely off topic questions. We did want our admin involvement to be as minimal as possible though.

Going into it there were a few key things we knew we wanted:

1. We only wanted positive feedback, so we did not go with voting things up and down, we only wanted people to be able to vote FOR something, not against it.
2. We wanted it to have a very low barrier of entry for people to ask questions. So we decided to not have a login. Which we knew meant we could not control gaming the system very easily, but we kind of liked that.
3. Although we wanted it to be easy to add questions, we still wanted good questions. So we decided to limit the amount of characters that could be used to 200. It was a somewhat arbitrary number, but the point was to make people think about the heart of the question and not ramble.
4. We wanted a broad audience, so it should be easy to share the question you asked with your friends. So we made sure each question had a landing page with a URL that could be blogged or given to friends and encourage them to go vote.
5. We wanted it to be sticky, interesting and as fair as possible. So we opted for 10 votes a day and a basic comment section for each question. Then later added a small blogging section and RSS features.
6. We wanted some self moderation by users. So we allowed flagging of questions and comments by anyone. These went to a queue and were reviewed by an admin . If a flagged item was approved then it could no longer be flagged. We later also added the ability for users to suggest a similar questions that should be merged.

Overall the site worked great, and was a success. We ended up with doing 4 phases.

Phase 1- Open voting, where anyone could post any question onto the site and vote 10 times a day on any question.

Phase 2- Site closed to new questions. We stopped taking questions about 2 months into it with almost 900 questions asked. Then allowed a month of continued voting on all questions.

Phase 3- We reduced the available questions to the top 50 and let voting continue. During this phase we also merged similar questions, based on user suggestions. To do this we combined votes from similar questions and if needed we reworded the question to include any content from merged question as well, we tried to minimize those changes though and leave the questions as intact as possible.

Phase 4- Initially we had not planned on it but it became apparent that we needed to limit the 50 questions and focus attention on the most popular so with about 20 days to the end we removed all but the top 20 questions. Many of the lower number questions at that point need too many votes to be viable for th top 9.

What did we learn:

1. Where people can cheat they will. We spent a good amount of time watching and deleting votes from people who voted thousands of times a day. Also there is really no fool-proof way to watch IP addresses and sessions and cookies to be 100% accurate without a login.
2. People have a lot of time to debate theology and talk trash to other Christians on anonymous forums. I often thought we needed to offer an apology to some peoples employers.
3. We love Ruby on Rails. It was confirmed that we like developing in this and is now where we are investing our development efforts for most new projects.

Let us know if you have any more questions and we will try and answer them in the comments.

I’ve written just briefly about The City, but as we get closer to launching the pilot version, I’m going to write much more. So let’s kick this off with a high level review of what The City is all about.

What is it?

The City is an online meeting place for Mars Hill that ties together existing community groups, service groups, and interest/strategically-based affiliations into a social network. This social fabric undergirds many forms of ministry and greatly enables the Ground War. It also enables linking the Ground War of many large communities (ie. networks of churches).

What are key themes in The City?

• Attractional - The City invites those not yet connected to form deeper relationships, get more involved, and become on mission with Mars Hill
• Developmental - The City is designed to show you the next step according to serving in your area of gifting
• Content Finds its Target - The City shows you information that you need/want to see (which you can fine tune). It does not deluge you with so much unimportant information that managing your involvement at Mars Hill through The City becomes a part time job. It also doesn’t show you information you shouldn’t be able to see.
• Administration at the Edge - The City is not centrally managed; every group leader is given the tools and ongoing training they need to effectively lead those they’ve been entrusted. For those business book readers, it’s more like a Starfish than a Spider.
• Real, not Virtual, Community - The City is all about real relationships, real ministry, real life and community change.

How is The City built?

The City is a Ruby on Rails 2.0.1 custom application developed and designed internally at Mars Hill. If you’re a developer or designer and a member of Mars Hill, come hang out with us and get involved.

Why not use another white label social network? (like Ning, etc.)

Stated simply, Mars Hill changes frequently and we need to have the agility to keep up with a rapidly changing organization. I also didn’t want to be tied into a vendor’s release schedule for new features…if we want to make something happen, we can do it.

When will it be available for Mars Hill?

Pastor Brad and I are working through the deployment schedule, but the bottom line is that it will be with Community Groups first, so get plugged into your group, go to the Syncs, and you’ll hear more in the next two months. A lot more.

Over the next several installments, I’ll describe each of the design principles in more detail, giving examples of what those principles mean in the life of The City. My last post, “Location, Location, Location” gave a preview of what favoring Real Community over Virtual Community, but I’ll outline this more fully.

I’m personally very excited about what will be happening through this avenue in the coming year, and I’d ask for your prayers for the team and the faithful volunteers that make all this happen.