If you’re finding yourself migration Subversion repositories to git, I highly recommend this article and accompanying scripts: http://blog.woobling.org/2009/06/git-svn-abandon.html

On the discussion of useful laws ¹, here’s one I’d like to propose:

For any organization that 1) delivers–unsolicited–advertising mail, phone books, or, well, anything else; and 2) includes on said material a notice informing the recipient that he or she should recycle when done with that material–

1. Such organization shall be required to fund forty hours of environmental research for every such item delivered.
2. The officers of such organization shall be flogged ².

(Edited by Mel)

So, you have a leadership role in your church. And for the fifth time in as many years, you’re gathered in the “fellowship hall” with other leaders and the pastor says:

We’re growing and that’s awesome. But we need to grow smaller as we grow larger. Last week, Jamie–you know, Jeremy’s sister, been here seven or eight years?–told me that another long-time member asked if they were new here!

Stilted laughter, nods of agreement–“Yeah, I’ve done that…”.

More importantly, some of our members, when they get sick or have other troubles, are falling through the cracks. We’re just getting too big now for the leadership to be able to take care of everyone. What we’re going to do is get small groups going. Now, I know we’ve tried this before…

And that’s when you try to decide whether to get excited now, and then give up later, or just give up now.

Because even though church small groups always begin with the best of intentions, with the most reasonable and laudable objectives, they also almost always end up, well, disappointing. Here are my thoughts about why that happens.

Dynamic and Diverse

Yes, “dynamic and diverse” small groups look exciting in the bulletin, but trying to create them almost inevitably produces the same disappointing results. It turns out that attempting to create dynamic, diverse small groups is actually pretty stupid. Why?

Because these attributes are exactly opposed to what attracted people to your church in the first place. Small groups that are truly created to be “diverse and dynamic”–that is, groups that artificially bring dissimilar people together for continually changing experiences and endeavors–are going to scare a congregation that sought out this church as a place of security and comfort. That is not to say that difference, change, and relevance are undesirable, but rather that they are the product, and not the producer, of a healthy small group.

At bottom, people go to church to find stability. This may be the “I don’t want to be challenged” stability, and it may be the “I need a place where I know I will be loved and encouraged” stability, but the heart of the matter is that church is a–for many, the–place we go to be safe. Difference and change, however, are inherently destabilizing. This is good on a personal level, or when organically developed–there is no growth, you know, without change–but when artificial or institutionalized, they inhibit rather than foster healthy communities.

Dynamism, in its most abstract form, is appealing to church and organization leadership primarily, if paradoxically, because it helps to create an atmosphere of emotional security. The term “dynamic”, as used by the seeker-friendly and megachurch movements, is a constrained definition referring to a particular service style: an entertaining, engaging, and well-run production-type worship experience, generally sold as something like “presenting relevant material in a relevant way”. Most churches, whether their services are “dynamic” in this sense or not, seek to promote an atmosphere of comfort, homogeneity, and stability in order to attract the “less devoted” crowd; they just keep those terms out of the marketing materials. “Dynamic,” entertaining services and swanky coffeeshop décor are carefully crafted to make the congregation–and especially visitors–feel safe, not challenged. The audience is in the familiar realm of the consumable, for better or worse, enjoying pleasant experiences with others who enjoy the same experiences.

Diversity is a little more clear-cut. We know what we want when we say diversity. Having a racially and otherwise diverse congregation and staff is appealing for a very similar reason: it presents an image of interpersonal harmony–however well-founded–that is profoundly comforting in our very unharmonious world.

While intentional, top-down efforts toward dynamism and diversity–at least in these forms–contribute to an atmosphere of stability in the broader church setting, in small groups they tend to do the opposite. For instance, we only have one idea of how to make small groups “dynamic”: switch them around every year (Please note, if you just thought that was a good idea, any small groups that you have leadership over will fail within the next six months). People came to your church to get some stability! Thirty 90-minute meetings is nowhere near enough time to forge a meaningful, trusting, and supportive community, especially with the expectation of having to do it all over again in a year. It’s barely enough time to learn everyone’s name.

And when we try to create a “diverse” small group, we tend to assign the small groups based on insurance commercial diversity: there’s the token black man, the token old lady, the token former druggie, the token “other race”, the token career woman, etc. Then we push people to stay in that group. So what happens when these “representatives of diversity” also have, by coincidence, completely different methods of studying the Bible? How does that play out? In my experience, this attempt actually produces homogeneous groups in terms of race and background who are incompatibly diverse in both methods of interaction and of study. “That doesn’t make sense. How did this happen?” Because your church is not all that diverse–in terms of race, economics, social classes, age or background–and by cherry-picking artificially mixed groups you’ve stuck people together who are not comfortable with one another. And, hey, this is the US of A. We aren’t that comfortable with diversity to begin with. Could you blame the people chosen to make the group “diverse” for seeing through this nonsense and checking out?

Required Studies

In your efforts to ensure that the church is growing smaller/bigger (and because he “doesn’t want to waste time of the small group leaders”–which may just mean he just doesn’t trust them), the pastor has established a curriculum and assigned it like homework in a seventh-grade English class. I’m not even going to bother with this. It just doesn’t work.

No, wait, I am going to bother with it. Did you like school?

“No. Well, actually, yeah–I liked that one class with the teacher who was always going off on tangents.”

I’m going to share something life-changing with you. Everybody feels that way! At least, everyone I’ve talked to about it. Tangents, bunny trails, call them what you will, interest us, excite us. Why? Because they’re RELEVANT. Not relevant to the entire school, the entire church, the entire “movement,” but relevant to the community created in that class, during that discussion, at that moment. Communities are forged in these kinds of moments, through these kinds of all-over-the-map conversations. These conversations cannot be led from without…because they, and the communities they create, are truly dynamic. Dynamic in the constantly evolving, chaotic, messy, eruptive sense.

The tendency in church leadership is to envision a false dichotomy between uncontrolled chaos and perfect order in small groups (and elsewhere)–and from there to imagine that unless the church leadership is extremely involved in every aspect that the former will reign. This is stupid. And arrogant. If God can use you, can’t he use the people he directs you to appoint? The leadership needed in a small group setting is not lecture-hall style didacticism, but rather intimate shepherding–and this is precisely the kind of care for which the pastor, recognizing the limits of his or her ability to reach an exploding congregation, has created the small groups in the first place. By forcing a small group leader into a specific channel of material, the church leadership essentially cripples the small group leader’s capacity for leading, guiding, and counseling those under his or her care.

As a note, one of the fears of tangential discussion is that an important point will be missed. Unless you’re changing up groups all the time, there will be another meeting. The point you were trying to make wasn’t that important, anyway. Sorry.

Throwing Out the Baby

“Our small groups aren’t working like we want them to, so we’re going to stop them and try something different.”

“Jane and Bob’s small group isn’t working, so we’re going to stop it, but Ralph’s and Sarah’s groups are doing great, so we’ll see if the leaders need anything from us to help them do even better.”

I’ve only ever heard that first statement. Is this some idea of fairness, or are small groups just an all-or-nothing game? I think it’s pride. The leadership says, “we’ll figure out a plan that works for everybody,” imagining that if they just think hard enough, just talk about it long enough, they’ll find the perfect idea. Completely, of course, disregarding the reality that each small group is a unique community made up of individuals with very distinct needs and personalities.

If a group is successful, if it is meeting the needs of the people in it and helping them grow closer to God, what on earth are you accomplishing by disbanding it?

Anybody?

Hello?

Ironically, while we rarely have a plan for dealing with the single failing group, church leadership wastes time worrying over what to do with the too successful group, the “big” small group. Aside from the futility of pondering this when first getting groups going, the usual solution is itself a problem: Split it into two. Realize that a successful group is successful because of the dynamics of that group. Splitting it up may disrupt that dynamic to the point of rupture. So, be very careful when going that route, and don’t just announce at the outset that that’s the plan. Just as with rearranging groups every year, a policy of splitting-into-two destroys the atmosphere of long-term belonging crucial to a successful, healthy small group community.

Leaders Matter

Leaders make or break a small group. Period. Unfortunately, the inclination of the church leadership is to pick tried-and-true ministry folk for their small group leaders, which sometimes makes sense but often means picking those who are already very involved in the church’s ministries because they have a “if it needs to be done, I’ll do it” attitude. In other words, people about three weeks from burning out. On the other side of this coin, pastors tend to choose small group leaders based on who the pastor thinks can do a good job, rather than who is interested in leading a small group.

Picking good leaders matter, but I think there are really only three things that you need to look for:

1. Not arrogant
2. Interested in leading the group (If they waffle at all, don’t push it)
3. Obedient to God

That’s it. More important than anything else (Are they good speakers? Do they have a lot of charisma? Are they popular enough?) is that the church leadership support the small group leaders. Treating them as little more than a lab experiment won’t work, and neither will hovering over their shoulder with “helpful suggestions” at every staff meeting. Instead, the leadership should ask the small group leaders questions and listen to their answers. What would make their groups better? What resources do they need? What challenges are they facing, and how can the leadership help? Attentive, but not micromanaging. After all, if we’re being sensible, if one group doesn’t work because of its leaders, that one can be altered or disbanded, without affecting the other groups.

Can Small Groups Even Work, Then?

Of course small groups can work. I’ve been in one. Notice that past tense, though. What happened? Well, some of the other small groups weren’t working. I’ve also been in groups that failed miserably from the start. In both cases, the end result was no group because church leadership kept getting in the way. The church leadership persisted in setting expectations that make no sense, particularly when adhering to their poorly understood theories of “dynamic and diverse” groups. In addition, the church leadership was unwilling to trust the leaders of the small groups to work in their own spiritual gifts for fear that the groups might take off in unexpected directions. (God forbid we be surprised!) And finally, the church leadership’s goals for the small group leaders–getting through a curriculum, maintaining a minimum attendance, including too many elements, etc–had nothing to do with the actual goal of a small group ministry, which is to provide community and more intimate group discipleship in a large and growing congregation.

In the small group that worked, the leaders of the group consistently chose to lead, regardless of what small group games the wider church leadership was trying to play. But when that church leadership rejected the group altogether, simply because other groups were less successful…

Well, that’s the attitude that keeps you showing up for that fellowship hall meeting every year.

So…want to make it happen this time? It’s very simple.

If you need a buzzword (it’s nothing to be ashamed of, lots of people have this problem) try “organic”. “Dynamic” implies change, but gives no reason. It usually devolves into change for change’s sake. Organic things, on the other hand, are alive, and change because they are living. Vitality drives dynamism. A small group that is succeeding will change as the growth of the group requires it. That means every group is going to end up different, and some groups will go the wrong way and have to be scuttled.

Let groups form around existing friendships. Individuals are much better at growth and diversity than organizations, anyway. Then let it grow organically, and don’t worry about how it looks. This is also the most effective way to avoid clashes over “ideas” and to keep the conversation-dominators from continually having new groups to dominate.

I’d suggest, instead, making it known that anyone who wants to start a small group can, with a minimum of requirements (basically, believe and follow the tenets to which all church members are expected to adhere), then have the individual leaders encourage anyone who shows an interest and ability to start their own group if they wish. Thus, off of successful groups may be a continual succession of buds, rather than a perpetual expectation of an impending split.

And absolutely the most important: install quality leaders in each group and have the church leadership be attentive. Feed the groups that are growing, and get rid of the rest.

First off, here’s what worked for me:

Edit the file C:\WINDOWS\system32\drivers\etc\hosts (that’s the path in XP), and add a line matching the IP address of the server (computer that is hosting the multiuser access and files) with the Windows’ computer name of the server. For example, if the server’s name is my-serv and the IP address is 192.168.1.10, add the line:

192.168.1.10  my-serv

Now, to the background and other (hopefully useful) information.

I’ve been trying to setup Quickbooks for multiuser access, and it’s been a pain, but along the way, I’ve found some useful information and tools available from Intuit. Apparently, setting up multiuser access works fine often enough, but when it doesn’t, it’s a bit of a hunt to find out why.

Read the Guide

The first thing–which I wish I would have known about and done before any installation–is go to the Network/Multi-User Setups page on Intuit’s site, and read the Network Installation Guide for your version of Quickbooks. It gives useful information, such as that client computers should be installed as “One User” (at least in 2009 Premier), because apparently adding the line “Or this will be a client computer on a networked setup” was too much work. The Guide is very helpful.

But what if it doesn’t work? For me, I could open a file in Single User mode from the client, but to open it in multiuser mode from the client, I had to open the file on the server, switch to multiuser mode, and leave it open. Then I could open multiuser on the client (I think, in essence, it was defaulting to the “Alternative Setup”). Not optimal.

Download the Network Diagnostic Tool

Intuit has a Network Diagnostic Tool. It’s actually linked to on the above referenced page, but I missed it there and it’s not highlighted in the various searches I did. Download it and then click (on the download page) the “How to Use the Tool” tab. There’s not much in the way of “how do I fix this” information, or even explanations of what exactly some of the tests are checking for. But it’s a nice starting point.

What Worked for Me

The router at my office, for which I am responsible, is a Cisco DSL router, which apparently does weird things to DNS. I’ll admit that my being responsible for a router that I don’t understand is a WTF and obviously part of the problem, but is one of those unfortunate realities. Anyway, it occurred to me that maybe if I define the host name - IP address matching directly, that could help (some of the information in the console tab of the Network Diagnostic Tool got me thinking along these lines). In XP, that can be done by editing C:\WINDOWS\system32\drivers\etc\hosts (see the start of this entry). And it worked.

Update 2009-11-29: Well, I’ve completed some of these plans (see below) and have Wistle back to “good enough” for me, so I’ve decided to forego the rest, at least for the time being. I have looked at migrating to hyde, a fork of jekyll (Jekyll is too “opinionated” for my taste), but have concluded that’s more work than I want for the moment. On the other hand, starting down that path produced an interesting library: svn-transform.

So, I’ve been pretty happy with Wistle, the merb app that runs this blog and fromgenesis.org. But I’ve been pondering the future of it. The design is somewhat monolothic, what with several libraries and such just stuck in the lib directory. I’m now thinking about focusing more on the app itself, rather than just the ability to store the articles in Subversion, but the current setup is a bit too interconnected. I would also like to easily re-use several of the bits in the lib directory in other apps.

The driving force here is actually the comments. The views I have so far are not real useful, and there’s no anti-spam measures whatsoever. And as I’ve pondered what I want to do there–and now with some time away from the original work–I’m thinking much more along “this is part of the app (the UI)” versus “this is part of the back end”.

So, refactoring is at hand. I want to strike a useful balance between “trash it and start over” and “make the changes that need to happen” (Although, since its mostly a for-fun project, if I end up trashing a lot, no biggee). I’m considering the best order to approach this; one in which I plan on doing the comments updates last, but at which there are a number of points at which I could stop and jump over to that. So, here goes.

Move to git

Done 6/14/09 - http://github.com/jm81/wistle

Wistle is currently SCM’ed in Subversion. I’d like to move it to git, and host on github. No particular reason, other than for the chance for some more learning. I’ve only done a little bit with git, and since it seems to be ‘the thing’ among the merb/rails folks these days. The little I’ve used it, I’ve liked it…

Libraries to gems

This is where the change really begins. I want to move libraries out to gems, because there’s no reason for these things to be tied to the app. I foresee five gems here:

1. Filters

   Done 7/9/09 - http://github.com/jm81/dm-filters. Unlike with jm81-paginate and jm81-svn-fixture, I did no cleanup on this library, but basically just copy/pasted the code and made it a gem.

   This is the library that allows for filtering text through, e.g. markdown, textile, smartypants, etc. libraries. It will also contain a couple built-in, which I could move out later. One of my favorite features of this lib is the ease of choosing between a variety of implementations for a single filter. For example, for markdown, I could use rdiscount or bluecloth, depending on which is available.

2. Pagination

   (Mostly) Done 6/23/09 - http://github.com/jm81/paginate - See TODO file for future plans for this gem)

   I know, there’s bazillions of pagination approaches out there. This gem would just be for adding a method to DataMapper classes and collections: paginate, which is just like all, but it receives a :page option (and receives or assumes a :limit option). The result has two extra methods: #pages is the number of pages given the current settings, and #current_page is the number of the current page (1-indexed).

   I should probably check what else is out there now, although I’ve never completely liked other implementations I’ve seen, mostly because I want to access the page number and total pages through a method on the returned collection. If there’s something better out there, I probably shouldn’t bother with the updates that are needed, such as adding the #paginate method to DataMapper::Collection.

   What I do have is somewhat based on dm-is-paginated.

3. Pagination-slice

   Update 6/25/09 - I decided this was unneeded. The jm81-paginate gem (above) now has a helper method (Paginate::Helpers::Merb#page_links) that does what I had planned for this slice to do.

   This involves figuring out merb slices, but that’s worth it. I have a helper (might be part of the first library) and a view partial that I use quite a bit, with slight variations. It’s based on someone else’s code, but I’m not sure I remember what.

   Anyway, I think I could create a useful slice, to make this code more easily reusable. I’ll see.

4. Subversion Fixtures

   Done 7/5/09 - http://github.com/jm81/svn-fixture

   Currently in lib/wistle/fixture.rb, this allows a fairly simple way to set up a Subversion repository (which I use in testing the Subversion-to-Datamapper stuff.

5. Subversion-to-Datamapper

   Done 7/10/09 - http://github.com/jm81/dm-svn. As with dm-filters, this gem works, but I haven’t put much effort into it.

   The current lib/wistle directory, the stuff that extends a DataMapper class to allow syncing from a Subversion repository.

(A possible sixth gem has to do with “attachments”, along the lines of attachment_fu. It’s not something currently required in Wistle, but I have one more or less together that works more reasonably to me than other plugins currently available)

New Wistle lib approach

Aside from the fact that the above needs to happen in order to simplify new updates, what really interests me is this part. I want to break up the process in the Subversion-to-Datamapper sync. In short, I want to place an intermediary, which is the Atom Publishing Protocol. That way, I can use Subversion to store and auto-publish to any blog app that accepts Atom publishing. The blog app, then, can also accept from any client that publishes via Atom. Both of these options are appealing to me, while still allowing the Subversion to blog app as it currently is without any change from the perspective of the article writer.

So, there would be two libraries/programs then, such as it is:

• Subversion to Atom
• Atom parser to Ruby model

Ideally, this could go in the opposite direction, so that, for example, I could publish via Atom from Word and it would commit to the Subversion and update the blog app. But I’ve not really investigated Atom to know if this would all be easy enough to be worth it.

Another issue this will create is adding some sort of user privileges to authenticate when users try to post articles, etc.

There will also probably need to be another library for updating the views and public files from Subversion, and (possibly again elsewhere) the methods for allowing the views and assets to be found in the right place in the file system based on which site is currently active.

Update app to new libs

This would actually be an ongoing process, updating the blog app to move from the existing integrated libraries to the new gems, including updating for any modifications to those libraries (which will happen in at least some cases). But at some point, I need to make a concerted effort to ensure this all has happened. Which leads to…

Clear separation of app and libs

By this point, the blog app itself should be a distinct entity. It would accept publishing adds, edits, etc. via Atom Publishing, and use the other libraries as needed. But it would not be tied to Subversion as the storage mechanism, and the gem could be used in other applications.

Update versions of datamapper and merb

Another thing that will need to happen, and I’m not sure when, is to update to the latest and greatest datamapper and merb versions, and the latest svn-client lib, which does have some changes. But those will need to happen at some point, at this if not before.

Fix comments

Hey, now we get to really fix the comments, because there’s not all that other stuff in the way. Obviously, this could happen sooner. It involves two major pieces:

1. Nicer looking default views.

2. Anti-spam. I’m currently looking at reCAPTCHA. Another possibility I’ve considered is that the first time a visitor posts a comment using a given email, they would receive a validation email. Since I have no intention of actually showing commenters’ emails, this should be workable.

   Update 7/6/09 - Minimal work to add recaptcha support. Commit

General app cleanup

Because, there will be stuff to clean up, right?

As a final comment, if anyone else is interested in working on this, please let me know: jmorgan at morgancreative dot net. I don’t know that this project would hold any interest for anyone else, but it would be silly of me not to ask, eh?