November 2007 Archives

I use IRC (Internet Relay Chat) quite a bit. If you don't know what I'm talking about or just barely or don't much know how to use it, that's why I'm writing this. IRC is similar to instant messaging, except that it's been around longer and it is primarily oriented around group conversation rather than individual-to-individual. For example, I hang out on #k-slug, which is a channel for the local Linux User Group. I also am on #jifty for Jifty developers and users to get help, #drupal-churches for people who use Drupal for church and other religious web sites, and a few other miscellaneous channels. So, I want to explain how to best use IRC if you're interested and tell you some things not to do.

First, you need to find an IRC chat room on the topic you wish to chat about. In general, if you don't know what channel to join, you probably aren't ready yet to use IRC. However, if you use an Open Source project or some local support group has a chat channel posted, you now have what you need. Find a client (I don't know about clients, find another web site for that) and join the appropriate server and then join that channel.

Second, be prepared to stay in that channel for a long time. The more you have your IRC client open, the better. Assuming you're familiar with instant messaging, you don't typical connect to your instant messenger and then immediately disconnect when those you want to talk with aren't around (or maybe you do). It'd be difficult to let other people start a conversation with you unless you stay connected a little while.

In IRC, this is even more important. Connect and stay connected. Many times the people in the channel are very busy and are connected while at work (myself for example). You might post a question about something related to the topic and not be responded to for hours on a quiet channel. If you expect to pop into an IRC channel and ask a question and get an answer within 5 minutes, expect to be disappointed. However, if you ask your question in a channel and no one else is talking on the channel you could be answer hours or even days later, if you stick around. Anyway, I see a lot of people pop into a channel I'm in, ask a question and then leave within minutes when I look in on a channel 30 minutes too late to have caught them and would have answered them.

Third, you also need to understand the lurker nature of IRC. If you look at a channel, many times there may be 10, 20, or more people listed as currently connected. However, of that maybe only 1 or 2 (or even none depending on the channel) are looking at that channel at any given moment. Getting mad that no one is answering is silly. They are participating in other discussions or are simply logging the channel for reference. For example, I am in 18 different channels 24 hours a day, but I only really pay attention to 4 or 5 of them and only in 1 or 2 of them 95% of the time I'm actually looking at the screen (I'm not actually awake 24 hours a day, though I sometimes come close). But I do watch for activity on certain quiet channels and will help you or talk to you if you're patient. Many of the regulars on IRC operate in a similar way.

Next, when joining a channel, avoid saying, "HI" or "hello" or "hey guys". That's an instant newby flag and first impressions are important. If you have a question on topic, just ask the question. You don't need to introduce yourself other than just being a member of the channel. You'll be taken serious in almost any channel out there. If you don't have anything specific to say that's on topic to the channel, just listen. If I go to a party where I don't know many of the people, I listen for a few minutes to get a sense of the group dynamics, whether people agree with my politics, what topics people prefer, etc. Then, I can start talking about things the others I don't know well can relate to. The same principle applies in IRC. Listen first if you're not sure how to join in and watch.

Finally, don't be a troll. Don't respond (i.e., encourage) trolls. A troll is someone who joins a channel to tick people off or who drags the conversation off-topic. Sometimes, the folks in #k-slug discuss Mac OS X or Windows or Python programming or other things that are sometimes related or sometimes not at all related to Linux, which is the group's purpose. These folks have been in the channel long enough that they are just making conversation and it's acceptable. However, if someone joins the channel and immediately asks, "how do i setup my bluetooth phone on my apple running mac os x?" they will not be well received. At all. This is a channelf or Linux, go find some Mac fanboys in another channel for help. However, if you've been in the channel for a long time and now there are other Mac users in the group, the question might irritate someone who thinks Linux is the One True Way, but the channel as a whole isn't going to descend on you out of irritation.

That's just some tips on how to use IRC. I hope someone finds them useful.

Cheers.

While working at my current job, we've used three different systems to manage our projects. First, we used Trac
, which I liked very much. As we transitioned from project management into user support after the first launch of the new web site and related products we tried to use RT
for project management, which I like very much as well, but turned out to be a poor choice for what we were doing. Finally, over the past few months we've implemented a new system during Drupal
, which has been moderately successful for us. I wanted to discuss the progression briefly and explain how to use Drupal for the task of software project management.

Initially we used Trac. Trac is basically a wiki + issue tracker + code browser + milestone manager. It does those four things extremely well together. You can create wiki pages for documentation very easily. You can easily link between wiki, issues, code revisions, files, etc. You can gather your issues together in dated milestones for releases. You can track all the activity of your developers from a central timeline. All of these were working well for us. The only major drawback is that my knowledge of Python (which Trac is written in) is limited and there are things we wanted to do with it that would have required more customization than Trac is really capable of without patching it. That wasn't a show stopper. I can learn Python and we could have lived without the customizations, but it was a drawback for us.

However, Trac is not a tool that works well for end-user support since it's email integration doesn't work very well and isn't quite as transparent as I'd like. Having used RT for end-user support and loving it for that purpose, we implemented that and transitioned to RT for project tracking as well. At that point, I setup a Drupal site to sit beside the RT site to hold documentation. As far as end-user support goes, RT is the bomb. The keys, as far as I'm concerned, is the ability to logically separate support issues into queues, being able to transparently integrate email, being able to link and merge various tasks together, being able to make private technical comments on a ticket separate from replies that go out to the person with the problem (that's a killer feature), and having lots of flexibility when it comes to building email templates and triggers that send email on comment... oh, and really, really, really flexible access control. I've not seen a system for incident tracking with end-users that even comes close (not that I've seen many such systems). I've also made quite a few customizations to the system to make it more useful for us.

As far as project management goes, the RT-Drupal combo was a failure. It caused a lot of headaches, there was confusion about what was happening, and we really didn't store much of any documentation in Drupal. We should have added RT as an end-user support mechanism and kept Trac in place without modification. Had we done that, I don't think we would have implemented the Drupal system we're using now, however. Basically, I/we decided that trying to use RT to track our software projects wasn't working for us.

I suppose we could have found a way, but we decided instead to give the Drupal Project and Project Issue module a try. This decision was made for several reasons. First, we'd made a strategic decision to use Drupal as the new base platform for our central web service, the Boomer Knowledge Network
. By reusing Drupal for project management, we could more effectively reuse our knowledge and even try a few things out on the support site that could be copied on the BKN. We weren't sure it would succeed and we might have switched back to Trac again if it hadn't.

However, our use of Drupal with the Project and Project Issue modules has worked out better for our purposes at this point than I think Trac would have. The Project module for Drupal provides little to no value on it's own for us except to break up our various software projects into chunks. The Project Issue tracker, on the other hand, has all the power we need. The only major drawback at this point is the inability to assign another user to an issue //drupal.org/node/4354">http://drupal.org/node/4354, perhaps, eventually they will even agree on a fix and apply a patch!
. Other than that, it can track pretty much anything we need it to in a way that fits our team's development style [# Our development style bears some vague resemblance to Agile, but much less formally structured].

The thing that's really helped though is Drupal's CCK module. This is a customization tool that allows you to add custom fields on nodes. The Project module has a system for building releases and such, but it's really strongly geared towards how Drupal's core, theme, and module code is released, which isn't precisely the way we release our work. Rather than using it, we built our own system by building a custom Release node and then associating custom fields to link that node to a project, setting a status (in progress or deployed), a planned delivery date [# usually within 2 weeks], and a list of references to issues that should be completed on release.

We then reconfigured the states that they are defined for issues so that we have a "fixed / ready to deploy" state and a "deployed / completed" state to match with our releases. Those working on a given release can change the state of all the issues to "ready to deploy" as soon as they get everything on that issue complete. Once all of them go light green, I "schedule downtime" [# I.e., I do it late at night when our members are asleep] and perform a code push and do all the configuration necessary to finish the production release [# Usually, this is a 5 minute process, but sometimes as long as 2 or 3 hours]. Then I can mark that issue as resolved.

We also have some documentation in the system, but we're not doing as well here as we probably could. I'm also starting to build some tools using more custom node types with custom CCK fields to handle idea gathering. I'd like team members to be able to visit a site and share that link in a way similar to Digg or Delicious within the office and I'm already a good ways along on that. We're building a review system so that other staff outside the team will be able to comment on screenshots and comps so we can develop a feedback system.

I've also figured out a way to get the timeline back, which was a feature I really liked in Trac. Using the Drupal news aggregator, I can pull the feeds for code commits, issue creation, releases, and even comments [# via the Drupal Comment RSS module]. Unfortunately, I haven't found a way to pull issue followups in a way similar to Comment RSS so those are missing still, but I may just build a Followups RSS module if I have to.

Anyway, I'm pleased with how the project modules are working in Drupal for us. It's a little more flexible than Trac is (IMO) and since I'm very familiar with PHP [# I'm unfortunately familiar with PHP, which is a language I just don't like for both idealistic and emotional reasons.] and with Drupal [# On the other hand, even though Drupal is written in PHP, much of its design both internally and aesthetically is quite nice.], the code customizations are a piece of cake.

Well, that was a lovely ramble. That's what I get for writing so late after working all day....

Cheers.