Edmug is north (notice the little 'n' not the big 'N' like Ollie North). Edmonton is the most northerly provincial (not including the territories) capital in Canada. We're 53°34' north. We just passed the longest day of the year which held 17 hours and 6 minutes of daylight plus twilight. Because of this and the great weather we've received this week, I spent a few hours siting on a local pub's patio with Jean-Luc David after he presented for Edmug. While we were sitting there it some how came up that Edmug may be the most northerly .NET user group in North America. I did some research tonight and we are (Anchorage has a Network Users Group). From now on you can think of us as the Northern Patron Saints of .NET Geekdom.

I'm the Igloo Coder and I should have figured this out just by looking at the ice block residence I have for the summer months.

In this, the final post in the User Group Startup series, I'm going to explore some of the ideas that we at Edmug have batted around. The ideas I'll present here are ones that, while possibly benefitial to you user group, don't directly the effectiveness of running a group or holding events. The one segment of your user group that they could influence is your membership. These ideas are meant to be ways to get out to more people and potentially make the existing members more active and passionate about the local community.

Extending your reach can take place two different ways. One is that you may be able to contact and affiliate with IT communities in smaller towns surrounding your location. The other way to extend your reach is to make contact with more local people who haven't known about or attended events. For some user groups stretching into a regional entity is not possible (the surrounding area might be supporting other user groups already) or desirable. Continually working to make contact with potential new members is something I believe that user groups need to do to maintain a healthy existence.

Reaching out to the surrounding geographical area is something that we considered a far off possibility when we initially started Edmug. Amazingly it only took a couple of months and some word of mouth before we had been contacted by people from around Edmonton. We are the most northerly INETA .NET user group in North America and the closest user groups to us are approximately 300 km (186.411 miles if that is your unit of choice) south. The next closest is over 500 km (310.686 miles) away. True there aren't many larger communities 500 km in any direction from Edmonton, but there are some that have developers living in them. Because the cities and towns that these developers live in aren't very large, they look to Edmonton as a hub of developer community activity. Again, because of distances these folks aren't able to make it to our meetings regularly, if the attend any at all. We've been contacted to try to setup livecasts of our meetings for people in these other locations. Another thing we've suggested, in an attempt to draw these small bands of developers under our umbrella, is offer to have our local speakers make presentations if they're in the area.

One could say that reaching out to uncontacted people in your local area is nothing more than having a recruitment drive. This is true. Once you have your group up and running, members and attendees are going to come and go for a variety of reasons. To ensure that the membership body stays healthy and active you will need to continually recruit new members through whatever means possible.

One of the tools we are developing to help us with our continual recruitment is a program we're calling the User Group Evangelists (watch here for more information in the coming weeks). The purpose of this group is to identify people that are active within the community and have shown excitement about the user group. We hope that by offering these people whatever benefits we can, they will in turn spread the word amongst friends, colleagues and coworkers.

Another idea to reach people is to have a user group podcast. At Edmug we have discussed this, but have yet to implement it. I'm not sure what the impact of this will be on reaching a new or different audience as its advertising will mostly be viral.

This concludes my post on Extending Your Reach and my series on User Group Startup Stories. If you have any other topic ideas, post a comment and I will see if I can continue to grow this group of posts.

In this installment of the second to last installment of this series I'll discuss one of the most difficult tasks you face while running a user group. Once you have a group started, meetings and events are being held, and people are attending you will have to figure out how to keep the momentum going. Having only run a user group for a few months I hope that I have it figured out so that I can both impart knowledge on you and keep my user group rocketing along.

One of the most obvious ways (to me anyways) to keep people interested and stoked about the group and it's events is by offering great content. Like I've said in previous posts, content is king. People will come out to your events if you have great content and you have a way to let them know about it.

Other, less admirable, methods of keeping people interested tend to be marketing fluff. This may include special attendance deals (i.e. swag, attend and get the promo code from our sponsor, etc.). If you decide to take this approach you will need to be very careful. Developers have an innate ability to see marketing fluff from a mile away. If the do see it, they won't pay attention to it.

Probably the bigger thing that can be done to keep the momentum up is creating and growing a strong local community. Admittedly this is far easier said than done, but if successful you will create a user group that will have great membership.

No matter what method you think you should take to keep the excitement about your group/event going, the one thing that will be at the foundation of all of them is effort by the user group leadership.

In the sixth installment of this series we'll discuss meeting and event content and how important it is to creating a great community. Developers, by our nature, are an inquisitive group of individuals. Most developers have realized that they will need to continually adjust their knowledge if they want to stay at the top of their game. Community, which is what we're trying to create through user groups and other events, is defined by dictionary.com as "sharing, participation and fellowship". The first word in that definition is sharing and there are a number of ways to include this as part of the developer community. I'm a firm believer that although developers and other IT professionals will come to user group meetings, code camps and other events to share ideas and make contacts amongst themselves, the main purpose for attending is to learn and expand knowledge.

Because the primary reason for attending events is to receive knowledge transfer, the content of these events must be a primary focus of the people organizing them. There are the obvious content statements such as .Net user groups focussing on .NET content, but the person or people responsible for content selection need to address it at a much more granular level. For example, if you are a .NET user group you should be looking at presentations on different languages, different areas of the .NET framework and different tools that are commonly integrated with .NET and the Visual Studio IDE. No matter your user group's focus don't be hemmed in by it. Open the content to topics such as Patterns and development methodologies. Most periphery topics like this can have demos and examples shown in a pertinent technology.

Where should you source your speakers from? There are a number of options available for finding speakers. One of the most well known is the INETA Speaker's Bureau which can provide, at no cost to the user group, up to three top quality speakers per year. This program is very widely used and thus requires advanced planning and booking. INETA will not provide the speakers to your group without you asking, so step up and ask.

Here in Canada .NET focused user groups have the ability to tap into the MSDN Canada Speaker's Bureau. This program is similar to the INETA program, but is open only to Canadian user groups and focusses, but isn't limited to, Canadian speakers. Again, like the INETA program, it is up to the user group to make the requests.

Another group to tap into is any Microsoft MVPs that you have locally. A big part of receiving and retaining this designation is community participation. Additionally these people have been awarded the MVP designation for their technical knowledge.

The fourth option, and in my mind one of the most important to the development of a strong community, is the creation of a group of local speakers. Finding capable people willing to take on the task of a presentation could initially be difficult. These people are out there though. I have found them by simply suggesting that their knowledge on a specific topic is significant enough that they should consider sharing it with a larger group, like our user group. It's amazing how positively people react to that suggestion. Like the speaker programs I outlined earlier, local speakers will rarely walk up to you and offer to make a presentation. You will need to search them and out and possibly nurture them. They payoff for doing this will be a stellar lineup of speakers for all your events. Another

When we were organizing Edmug we realized that unforeseen circumstances may cause our scheduled speaker(s) to be unable to make their event. If this happens we wanted to be able to provide the attendees with a substantive event. To ensure that this will happen we have required every member of the user group leadership to have a presentation available at all times. If the scheduled speakers can not make the event it will be one of the leadership who fills in the time slot.

The most obvious and most common method that user groups use during their meetings is a single person presentation. While this is a very good format for meetings it is not the only one that you should consider. Larger conferences have started to use presentation techniques such as Birds of a Feather and Grok Talks. Both of these have circumstances that they work best in. Birds of a Feather sessions are meant to be used in a more intimate (smaller group) environment and should have significant crowd and speaker interaction. Grok Talks allow you to have many people make short presentations on many different topics. The draw back of this format is finding a large enough number of people who are willing to make a small presentation. This may be a great way to give attendees and members a way to break into the speaker circuit without the pressure of having to do a full presentation.

One of the first things that we decided when we were starting our user group was that "Content is King". We spend a great deal of effort searching for speakers, ensuring their content is appropriate and meeting the requests of our members and event attendees. Some people have suggested that content should not be king and that we should concentrate on creating a community. I think that by having excellent content we will, and do, draw significant numbers of people from the local area together and from that we build the community.

It's so darn beautiful outside today that I thought I'd sit on my deck and add another entry to my series on User Group Startups. This time around I'll write about meeting and event locations. If you are looking at holding reoccurring meetings, as most user groups do, location selection is a big deal. If you have to change your meeting locations regularly (I might even argue that if you have to change them at all) you run the risk of confusing and alienating your members. Holding special events such as code camps at different locations is not such a big deal as they tend to be viewed by the membership and organized by the leadership as one off events. No matter which type of event you are holding, location selection is very important.

Before you start looking for a room or building to use you should put thought into which area of your city your want to hold your events in. Consider where the majority of your membership will, or does, work. Once you have become as comfortable as possible with the the location of the majority of your membership, then you should consider if that area is a feasible candidate for holding your meetings. You will never find one location that is perfect, good or even adequate for all people that may attend the events. Instead of worrying about that, try find an area that will work for the majority and is accessible for the remainder. Consider factors such as public transit availability and parking.

Now that you have the area narrowed you can start looking for facilities to use for the event. There are a large number of options for you to consider here. Because you are running a lightly or non-funded organization you probably won't be able to afford some of the options that I list here. That said, working with restricted funding can open the doors to some very nice facilities at no cost. Below is a list of possible venues. No matter which you choose to use, always ask them for a discount (you're a community group and, most likely, non-profit) or ask them to sponsor you outright and waive the cost.

• Colleges/Universities/Public Schools -- These usually have great facilities that are very conducive to presenting. You may run the risk of having certain times of the year where you can not gain access to the facility due to holidays or usage conflicts.
• Company Board/Conference rooms -- Many companies will offer the use of their office space during non-business hours. Things to watch here are the seating capacity of the rooms and building entry requirements during off hours (passes to open doors etc.)
• Government facilities -- Being a community group might get you in the door here.
• Public Libraries -- This is what Edmug uses. We worked out some sponsorship with the Edmonton Public Library that provides us with a conference room at no cost.
• Local Microsoft offices -- If you're a MS technology focused group why not give them a try. More than one user group in Canada is using their facilities.

Choose your location carefully and make sure to take into consideration the needs of your attendees. Make sure to provide them with knowledge about parking, public transit, directions to the facility and directions to the room once they are in the facility. The easier you make it for people to come to the events, the more often they will come back.

In this installment of my Startup Stories I'm going to talk about the hardware and setup you'll need for your meetings. When you attend events, whether they are company meetings, user groups or conferences, there is an expectation of that a certain amount of preparation will have been done in advance. Hopefully the ideas that I will talk about here will help you to achieve meetings and events where no attendee ever things about the preparations involved.

Meeting/Event setup involves a number of different things.

1. Ensure your location is booked and confirmed prior to the event date. (more on locations for meetings in a future post)
2. Ensure your catering (if you have any) is booked and confirmed prior to the event date. Also ask that they arrive and setup prior to your attendees arriving.
3. Have the handouts (for us this is a meeting sheet and a separate feedback form) printed in advance.
4. Have your leadership or helpers arrive early. We have our location booked from 5pm to 9pm and we advertise our events with the doors opening at 5:30pm and the presentations starting at 6pm. The group leaders and helpers are asked to show up as close to 5pm as possible which gives us half an hour to prepare the room, swag, handouts and test hardware.
5. Setup the welcome/registration area. At Edmug events we have a single folding table at the door. Our Membership Director is in charge of this area and ensuring that we have our handouts in order for the arrival of the first attendees. One of the things that we do in the half hour before we open the doors to the event is collate the handouts so that the Membership Director can quickly pick up a package and hand it to the arriving attendee. If possible also have pens that can be loaned or given to the attendees for the purpose of filling out the feedback forms.
6. Setup a table and chair for the presenter to work from. It seems that the common thing to do is place a table at the front of the room, angle it so that the speaker can see both the presentation screen and the audience, and place it off to one side of the presentation screen. Another thing to do is ensure that there is adequate room for the speaker to walk around the table from either side and access the presentation screen or the audience.
7. Setup the audience seating area. There are a number of ways to do this, but the two most common are theater style (all the chairs are in rows) and classroom style (chairs surrounding tables). Both setups have their place and it's not my place to tell you which will work best for you but here are two things to remember. First, classroom style setups offer far less seating capacity. Second, if you are expecting your attendees to bring and use laptops having tables is a must. Edmug uses the theater layout for our events because of the need for seating capacity and not yet having seen anyone bring, and use, a laptop to an event. No matter how you setup your room there is one thing you will want to keep in mind. Ensure that your attendees can move around the room, including in and out of it, without having to walk in front of the presentation. This can be done by including aisles from front to back through the chairs as well as room to move across the back and to the door.
8. Setup and test your hardware. Almost every meeting or event will have a hardware need. Make sure that you take the time to setup the projector, run the necessary cables and do a system test that includes testing the presenter's system and any internet connection that may be needed. Part of hardware setup is hardware preparation. I suggest that your user group invest in a hardware kit for meetings and events. It doesn't have to be much, but it should include the following things:
   • Monitor extension cable (longer is better) -- Staples
   • 2 power extension cord each about 5 meters in length (1 for the presenter's laptop and 1 for the projector)
   • Mouse
9. Prepare water for the speaker. Either take bottled water from you catering, or bring bottled water if you don't have catering, and set it aside for the speaker.
10. Setup the swag in a conspicuous location that is easy to access when it's time to hand it out.
11. Assign people to feedback form gathering duty. This will help the end of the presentation transition smoothly into the swag give aways.

This list represents the items that we (Edmug) have learned by watching other events as well as putting on our own. By no means is this a comprehensive list that will ensure your meeting or event runs smoothly. If you have other ideas please leave them in the comments.

John Bristowe's Developer Night In Canada just released its latest episode featuring a talk with D'Arcy Lussier. Mister Lussier talks about how INETA helps with user group operations, support and knowledge. D'Arcy even went so far as to mention Edmonton's newest user group (us for those of you who add 2 and 2 to get 5). To quote D'Arcy "The guys there (Edmonton) are really on fire. They have a good executive in place and they're really rarin' to get Edmonton hot...". I agree with him whole heartedly. The leadership that I'm working with (Stevie Y, Steven R, Justice and Brad) are rockstars. They have taken this opportunity and hammered the nail over and over again.

These guys constantly amaze me with their passion, dedication, skill and knowledge. I have to admit that I was terrified at our first meeting. I was scared that we would have first event jitters (namely the idiot president would get up and bomb the intro talk). I was scared that we wouldn't be as prepared as we needed to be. I was scared that we would be missing hardware. I was scared that the freaking library would burn down! In case you don't understand how scared I was imagine the first time you meet the little lady's parents....and you're hung over. Yah....scared and nauseous. The thing that was great about our first event was that none of my worries came to fruition (except maybe the president bombing). The only reason that the meeting was so uneventful was because of the guys that are running the group. To the four of them, hats off folks. Okay put them back on now or Justice may get jealous of your hair.

I'm the Igloo Coder and I'm starting to tear up. Maybe it's time to stop biting my finger.

Yesterday and today I spent the better part of the day setting up a Cruise Control server for my dev team to use. This is my second attempt at this task. On the first attempt I made the mistake of trying to piece together our nAnt build files so that they could be called by CCNet and in the end I wouldn't have to do much work. Well, that was a gong show and by the end of my last release cycle I had quit using CCNet.

This attempt will be different (I hope). One of my biggest concerns during the first attempt was that I didn't mess with the versioning system that we were using. Our nAnt scripts were setting the software versions to a pattern like this:

  5.0.1829.1

The first two sections of the version number were static for each release cycle of the software. The last two section change based on month, day and build attempt. My worry was that, by changing the way the last two sections were generated, I would be doing something awful. The fact is, as long as I change the number sequence between development cycles (i.e. going from version 5.0.x.x to 5.1.x.x) I am preserving the version sequencing. Once I got this all figured out in my puny little head (okay, it's a big, freakish watermelon with a puny brain) I decide that I would attack the CCNet implementation by starting over from scratch on how we do things when building.

So far I've changed our process from nAnt to CCNet for source code gets and cleanup, versioning and build task sequencing. All of this has gone fairly smoothly and I've actually had a couple of revelations other than the versioning thing. The way the previous person had configured nAnt was to get the latest version of the source code down into a working folder and then copy the necessary web projects up to the inetpub\wwwroot folder. I'm not sure the exact reason for doing this, but it did allow us to just open the VS IDE and have the solution load up and be in a runable state. In the interest of trying to build multiple different major versions of the application on the same build server, I did away with this and just downloaded the latest version of the source code to a working directory for that development cycle. I can no longer fire up the solution in the IDE, but if I have to do that I should be using a dev box and not the build box. So far this is working great and I'm looking to expand on the idea by moving more of the referenced items into these development cycle areas.

I have run into one problem in this process. The environment that I'm working in has our development/testing servers, including the build boxes, in separate domains from the main company domain (lets call it the DevDom). This is fine until you add in the fact that the source code must reside on a server that is in the company domain (lets call it ProdDom). My CCNet build server has to talk from the DevDom domain to the ProdDom domain to pull down the latest version of the source code. When I'm logged in interactively on the build server and I've provided the correct credentials to manually establish a connection to the share holding the source code I can manually start the CCNet server (not the service) and everything runs smoothly. When I start the service all I get is an error saying that the sourcesafe.ini (yes I'm using VSS) file doesn't exist because it can't authenticate to the server and share that it resides on. So whats a good looking lad like me to do?

I can beg with the networking folks to give permissions to the VSS location for my service account, but I can almost guarantee that won't happen. Does anyone have any ideas?

I'm the Igloo Coder and Continuous Integration isn't all that continuous if I have to kick the build server off every time someone checks something in.

Update: The build server is not in a domain it is in a workgroup all by itself (the workgroup name is the same as the server name) and I have no ability to log onto this server with any of the ProdDom user accounts. Instead I use accounts that are local to the build server. I am a full administrator on that server though and can add and modify any accounts that I want if they are needed.

In installment three of my User Group Startup stories I'm going to discuss ways to make contact with the developers in your community. There are a number of different ways that we've used with Edmug to make contact with our community. I'll comment on those, plus I will briefly discuss a few that I've heard from other user group leaders.

Making contact with your community is one of the most important things that your Membership Director will do. Although you don't need monumental attendance numbers for your meetings or group, making your events known to the largest number of people will create the most technically and professionally diverse group of attendees possible. This is important since one of the greatest benefits that any group member can get from your events is the ability to learn from people in different situations, companies, roles and experience levels.

In Edmug we've used only a couple of different techniques to reach the people in the community. The one we've used the most regularly is an announcement newsletter. Our newsletters are nothing more than an email that we send out to our distribution list. In the newsletter we include information on our next event, a listing of upcoming events in the local and virtual communities, comments on sponsor discounts that are being offered and a small paragraph on the user group in general. There are two key pieces of information that we include in the newsletter. One is a link to directions for getting to our meeting location. The second is a sentence that explains that our user group is free for attendance and requires no registration. These have been the two most frequently asked questions that I've fielded through email or in person and if people are worried about how to get to your event or how much it will cost, you need to proactively promote this information.

We also have created two different websites (Edmug.net and bloggingonit.com) which we are using as portals for the Edmonton .NET developer community. The Edmug.net website is a collection of information pertaining directly to the user groups activities and it's members. BloggingOnIT.com is directed at creating a central community for the IT bloggers within Edmonton. Although these two sites are serving two different purposes, both are important ways to get information out to current and potential members.

In addition to these two methods we have recently started a program we're calling the User Group Evangelists. People will be asked to participate in the program based on their enthusiasm in the local community. In return for them selling the user group via word of mouth, blogs and/or email they will receive information on upcoming events, priority registration and other benfits. What we're hoping to accomplish is a group of people that help to spread the word about the user group beyond their cubicle or close friends. We hope these people will help us reach deeper into the development teams of the larger IT shops in and around the city as well as offer substantial feedback to help guide the group going forward.

It's all well and good to have a number of different channels to communicate with your community, but you must also know and understand what is driving these people. Running a user group based only on the desires of your leadership will alienate membership very quickly. Edmug has been very proactive in soliciting information from our event attendees and the people that are visiting our websites. When using Dot Net Nuke as the platform for the Edmug.net website, we have run monthly surveys aimed at gathering information about the running of the user group and what content members would like to see. I'm a firm believer that this, along with impromptu surveys during meetings, is the information that should be used to guide the direction of the user group.

Recently there was some discourse amongst the members due to a presentation that didn't meet their specific expectations. One of the biggest concerns was that going into the meeting they had no idea what level of discussion to expect. This was a valid point as all we were doing at that time was announcing speakers, topics and dates to the members. We listened to this and within days had implemented a topic level number system that would adequately tell what difficulty to expect from a meeting. Not knowing that the members would have liked this information was an oversight on our part, but ignoring it would have been suicidal. Never underestimate the desires and whims of your members. They are why you exist.

Once you've decided that you are going to start a user group and you're going about it with passion and conviction it's time to get together a leadership team. I want to emphasis the word team here. The local user group that I attended before helping to found Edmug was run by two people. One of the things that we noticed, and voiced while planning our new group, was that the two leaders of the previous group were stretched very thin. Let this be fair warning to you. Starting and running a user group well will take up a significant number of hours each month. You can not expect to show up for the meetings and have everything fall into place. Good meetings take time and planning. The more people you delegate work to, the easier it will be on you.

When we were first starting out we decided very early on that we wanted to everything that we could to make sure that no one person was doing so much work that they would become burnt out or disinterested. Essentially we decided to protect the passion (I'll get to passion a little later on). To try to stop this from happening we went with the INETA recommendation for a user group board: President, Vice President, Membership Director, Program Director and Treasurer. The main reasons behind this decision is that we could see each role having a very distinct responsibility and the number of roles would spread the workload out nicely.

Roles need people to perform them. Unconsciously we did not attempt to fill the roles, instead we fit the roles to people. We put the roles out on the table and let people choose which they wanted. I can hear people asking the question "Shouldn't we put the person with the most applicable skills or experience into that role?". Based on my experience, I say no. Again it boils down to passion. If you have passionate people, they will search out the roles that they want and the combinations that you initially make you wonder will surprise you. People with passion see no skill, comfort or prejudicial boundaries. Leaders with passion will instinctively help their peers without thinking. All of these things are a part of what can make a user group successful.

One of the first things that happened with our group was the resignation, for personal reasons, of our initial President. One of the great things about having a leadership that consists of five members is that, although we'd lost a valued member, we had a small amount of succession built in base solely on volume of bodies left in the leadership group. When you have numbers in your leadership, replacing a person does not become a scrambling situation. Instead you are able to sit back, evaluate what your needs are, listen to suggested names of people that are already involved in community, talk to other community members about their interest. Like selection to any team, you need to be concerned about team cohesiveness and passion. Take your time and promote internally if desired or nominate a temporary role holder. One of the ideas that we had, which we did not specifically act on, was to bring in a person for an "intern" styled trial. We backed away from these ideas because we felt is was very pretentious of us, a month old user group, to be interviewing for roles.

Without going into extensive details about the duties for each role I'd like to touch on the topic. One of the key things to remember about the leadership of your user group is that these people are volunteers. If you can assign duties to people based on their proximity to a location or their ability to travel easily you will see better results. As an example, two members of our leadership work very close to our meeting location while the others work a number of blocks away. The guys that are furthest from the meeting location will either walk or drive by the donut shop so they are tasked with bringing the donuts. The two people who are located close to the meeting rooms are partly responsible for being at the meetings early to perform setup.

As you can tell I'm a big fan of having multiple leaders on the board for a user group. That said, it might not be all the people resources you need. One of the primary focuses of any user group should be to reach out to the local community and inform, welcome and educate all people no matter their dedication to the group. We've batted around a number of ideas for this within our user group leadership. One of the great ideas is that we should start an Evangelist program. Evangelists could take many forms, but at the core they are an extra tool for our user group to reach out to the community through. We've thought about having blog evangelists and corporate evangelists as we see these two areas as having significant exposure to the mass of the developer community with the city and surrounding area. The idea of an evangelist is good, but we need to offer something to these people that sets them apart. As we essentially are a non-profit group, we can't offer much to these people. What we've thought of are two things: advance knowledge of upcoming events and some influence over the content that we try to acquire for the events.

User Groups live and die by the direction, passion and commitment that it's leadership brings to the table. That said, the volunteer leaders need to have consideration shown for their situations. Because of personal commitments no one user group leader can be Mr.Do-It-All and should look for help from within and use it's membership to help when and where possible. In the end, user groups are people working for people. Pay attention to the people and you will be one step closer to succeeding.

If you came to me and said that you were thinking about starting a User Group I'd ask you one question: Why?

The reasons for wanting to start a User Group vary. Perhaps the city/town that you live in doesn't currently have a group. Maybe there are groups but they don't focus on the technologies that you're interested in. Because there already was a .NET User Group in our city, our reasons were slightly different than most. A number of us attended the existing group's meetings religiously but were disappointed with it's inability to capture and drive the local .NET developer community.

Equally as religious as our attendance at the meetings was our attendance at the local pub post meeting. These informal meetings became the incubator for Edmug. A great deal of our inspiration came from two things that were obvious to us early on in this incubation period.

First, we felt good about the fact that there were about eight people consistently showing up to user group meetings that provided no content. We had also noticed that, although meeting attendance was low, events that had known speakers or content would draw five times the attendees. From this we knew that there was a community that had significant attention span and a thirst for content.

The second thing that we noticed was that the group of us that were sitting around the pub table were willing to make this happen. Without exception we wanted to pass our excitement for our local community and for the industry in general. There was no discussion of meeting the big name speakers, hoarding or even receiving of swag, or the possibility of personal prestige.

Discussions around the reasons for starting our group were not 100% innocent. One thing was very apparent. Each of us selfishly wanted to be in attendance for the best content that could possibly be brought to Edmonton. Of all things that any group needs and perhaps needs a greed for it is content. I'll cover this in a future post entitled Content, Content, Content.

The inspiration behind the formation of our user group was community and content. These two things are the cornerstones of a great group. Not only do they need to be strong roots for the group, but they also need to be nurtured and attended to once the group has been established. Again, another item for a discussion in a future post. Next time, Running with the Right Crowd; A discussion about the people running a user group.

I'm going to start a series of posts on what I've experience while Brad, Justice, Stevie Y and Steven R have started and been running the Edmonton .NET User Group. This series will not even be comparable to the nAnt Series (all 8 parts) by JP Boodhoo, but I gotta share what little knowledge and experience I have.

I'm going to tackle this in a number of posts that cover the following subjects:

• The Inspiration
• Running with the Right Crowd
• Knowing and Meeting Your Market
• Having the Right Setup
• Location
• Content, Content, Content
• Keeping the Ball Rolling
• Extending Your Reach

These are my initial thoughts so we'll see if I can stick to them or if I'll end up expanding on these as I get going.

I'm the Igloo Coder and I'm going to play nice for a while.....now gimme my ball you little bastard!

Who would ever have thought that that a post titled like this one would have the possibility of evoking thoughts of hockey? If this is what you thought, then shame on you! Why wouldn't you think of the upcoming Edmug meeting? In the case of June, why didn't you think of the TWO upcoming Edmug meetings?

You read right folks we're having two great events during June! On June 27th at 5:30pm Edmug will be hosting Jean-Luc David who will be presenting a 200/300 Level talk on Atlas/Ajax. Having seen Jean-Luc's voracious appetite for Montreal Smoked Meat Sandwiches, I can only imagine his passion for this topic.

The second event of June is happening on June 29th at 5:30pm. At this time you'll be able to see James Kovacs speak on Enterprise Architecture. I've heard James speak on 64-Bit software design concerns and I'm stoked to hear him talk on anything.

So folks, book a night with the Geeks of Edmug (the nudie calendar featuring me as Mr. January is due out for a drunken summer holiday near you <shudder>). If you're looking to get advance notice about events and promotions offered by our sponsors, drop by the Edmug registration page and sign up for future newsletters.

I'm the Igloo Coder and if you're still fighting off the urge to vomit, I'm really sorry about the image I painted....now I have to go get a bucket for myself.

Hacknot posted a comprehensive writeup on the traits, skills and requirements of a Technical Lead. As a Technical Lead the 19 items listed all hit home. Some are things that I consciously have thought about in my work environment. Others, like Mistake #18: Failing to demonstrate compassion, I've thought about repeatedly in my personal life, but I've not thought about the impact and consequences of applying this to work.

This post is the authority on how to approach leading a team of technical people. Read it, absorb it, and continually return to it and I think you will be a better person and professional for it.

I'm the Igloo Coder and I've still got a lot to learn.

According to Rob, if I'm not posting about my schedule for TechEd I'm a nobody. I'll have you know Rob that my mommy says I'm a somebody! And if you don't believe that I'll make you sit on the floor of the cab next time! Take that VB boy! ;)

I'm the Igloo Coder and I know that my week here in Edmonton will be much more fun that getting geeky at TechEd, or swag from TechEd, or going to Fenway Park, or getting pissed in some different city, or telling more people about Bovine Artificial Insemination techniques. Yah. It'll be better.....

Although I'm not using TFS (I hope to be very soon), these Sidekick products (Version Control and MS Build) by Attrice look very interesting. From what I can tell on the website both products appear to be free for use in both commercial and non-commercial situations. They even have the source code available if you want it. Check out the blog and subscribe to the rss to be notified of releases.

I'm the Igloo Coder and my sidekick is out to lunch.