Hamara Team

From Hamara Wiki
Jump to: navigation, search

Hamara Team

This page is designed to show various internal teams which are working currently on hamara project. Each team has it's own responsibility and has a leader who will be responsible for any concern in the respective team. The goal is to document everything that is important for people who want to help and maybe later join the corresponding teams. If you're part of such a team, you should check out the guidelines for internal teams, which provides information on creating and keeping a successful team.

Overall leadership of all Hamara Teams rests with Vikas Tara, founder of Hamara, if you have questions, concerns or comments he can be reached at "vik (at) hamaralinux (dot) org"

This is our currently dedicated team.

Founder Developers

Vik Tara

Amardeep Singh


Developers

Sagar Ippalpalli

Raju Devidas

Abhijith PA

Anant Saraswat

Gurvinder Dadyala


Designers

Sam Sayer

Joshin Martin


Testers

Aparna Bhat

About Leadership

It's best when someone is leading the team. Usually this happens naturally, the one that does most is usually the leader. The leader doesn't dictate everything however, he merely pushes forward the agenda of the team. He creates the consensus and nudges kindly the other members to do their share of the work in that direction.

If you're the de-facto leader and decide to change your priorities in such a way that you can't continue to assume the lead, inform the other members and get them to take over your responsibilities.

Teams Guidelines

Guidelines for Hamara Teams:

This document tries to summarize good behaviors that will make a team more effective within Hamara in the long run.

Communication

If you have a private email alias as point of contact, you should make sure to answer most of the mails within reasonable delays (1 week).

Don't fear to say "no, we won't do that because...". It's far better than no response at all.

Don't fear to say that you don't have the time to implement the request. Seek for help in that case, try to tell the requester how he could help you. Register the request in your request tracker at the same time.

Tip: Don't delete the email from your inbox until someone has replied. Have a discussion within the team to make sure that one person does this at least. Periodically review the messages without answers and take the time to reply, if someone else should have replied, ping him/her at the same time.

A public dedicated IRC channel is almost always a good idea. It's particularly interesting when you face many small support requests. You'll have permanent members that will gain knowledge from your answers and answer for you when you're not available. It's time saved for you, because those people would have mailed you otherwise.

If you find out requests concerning your team in devel@hamaralinux.org or users@hamaralinux.org , reply and indicate where they should have directed their request.

Documentation

Create a FAQ with answers to most common requests. Point people to the FAQ whenever you have an occasion. If the FAQ is in the wiki, ask people to update it with the information that you provided them.

Include in the FAQ information on how people can help you. Point them to the VCS that you use.

Try to create some internal documentation documenting your processes, your past choices, and any complicated setup.

An internal changelog file is a good start.

A team that works is able to assimilate new members quickly. It means that non-members have access to enough information to get their hands dirty and start helping. It also means that you should reply to people who are trying to help out. Ideally, once a new member is integrated he gets access to the remaining of (private) documentation and can be quickly effective.

Infrastructure

Document your team in [[1]] . Use this space as your official web page if you don't have another dedicated presence on the web.

Make sure that the information on http://www.hamaralinux.org/intro/organization is up to date.

Setup a public request tracker. You can use a pseudo-package on bugs.hamaralinux.org, a dedicated request-tracker queue on rt.hamaralinux.org, or a tracker on an Alioth project.

Composition and internal organization of the team

It's best when someone is leading the team. Usually this happens naturally, the one that does most is usually the leader. The leader doesn't dictate everything however, he merely pushes forward the agenda of the team. He creates the consensus and nudges kindly the other members to do their share of the work in that direction.

If you're the de-facto leader and decide to change your priorites in such a way that you can't continue to assume the lead, inform the other members and get them to take over your responsibilities.

Be honest and recognize when you're too busy to assume your responsibilities. Pick your favorite in the list of people who recently helped and ask her if she would like to join the team. Propose more rights/responsibilites to any "assistant" that you might have already recruited in the past.