Thursday, January 23, 2014

Joining the Project

1) Select an IRC client and join the channel for your Team project; peruse the history and listen to current traffic; blog about your experiences.

I have had no experience with an IRC client, so I googled "best IRC client for Mac" and got a couple of choices.

I decided to go with Colloquy.  
The UI is great and it feels like a Mac app.  

After registering my "nick", all systems were go.  I joined the #djano room and the #django-dev room.  The #django room for users was very active, but I was disappointed to see that there was not a lot of activity in the #django-dev room.  I did not interact, with the community I just "listened".  There was one user in particular that wanted to use Django on their site and was getting a lot of help.  I feel confident that if my team has any questions- answers will readily come from this community. 


2) Join the electronic mail list and/or newsgroup for your team project; select an interesting thread and explore it; blog about your experiences.

Our team collectively decided to join the following mailing lists:  django-users, django-core-mentorship, and django-developers.

Under the django-developers there was a ticket request review which caught my eye- after clicking and glancing at it- I am beginning to see how we will interact with the community regarding our bug fixes.   I don't think it's required to put your ticket revisions on the mailing list, but the contributor got a lot of feedback regarding his fix which I'm sure our team would appreciate.

The Reading

Our class is using the text Software Development:  An Open Source Approach.  Much of Chapter 2 in this text was review- as a class we've already talked about this material or seen it somewhere else.  I did think that the IRC etiquette lessons included in Chapter 3 of the online text and in Chapter 2 were good to look over.  Most of it was common sense, but still good to review.  Chapter 3 was more "getting started" material and (mostly) all review.  I will make it a point to go back and read The Bug Tracker section more thoroughly within the week.

Thoughts

Two of my friends who are applying their BS's in Computer Science to software engineering in the real world, have very different work environments.  Friend A works at a place where there is a strict no-finger-pointing-policy, while friend B works in an environment where finger pointing is part of that company's culture.  I'm assuming that both of these company's get their work done, but it is done in such different ways.  Pleasant work environments vs not-so-pleasant work environments.  This kind of goes back to the reading from last time-how the author thought that a charming leader was key to a successful project:  he fluffed his beta-testers/co-developers when needed (praising them in emails, etc) and charmed them into doing hard work.  Here he's clearly trying to create a pleasant "work environment" or I guess- pleasant community-experience in this case.  Let's just stop pointing fingers and get the work accomplished.  Shall we?!

No comments:

Post a Comment