BugZilla as a task setting and work control system. Real life experience

Planning, setting a task, control are one of the important principles on which project management and web projects are built in particular. And in the process of managing remote teams and organizing the interaction between them, one cannot do without using systems of setting and controlling tasks.
In this post I want to talk about the most popular BugZilla bug tracking system and its successful implementation and operation in the Tvins web-studio . For some reason, in Habré, Bagzilla is always referred to as a swipe. But no one has ever stopped her in detail. And in vain ...

At first glance it seems that here the devil will break his leg. But when you work in this system, you realize that everything is well and accurately thought out. The system has the greatest potential, it is simply customized and is easily integrated into the process of developing web projects.

Preamble

Frankly, everything was like ... I hope the leadership will not beat me and will not dismiss. I came to work in the company as a young and not experienced project manager. He quickly mastered the entire production process and merged it entirely. Began to lead projects: identify the needs of the customer, translate all this into the language of the web and form tasks for developers.
')
The company grew and developed. Projects became more and more complex, but the organizational processes when working on projects remained unchanged. Everything was utterly simple - all tasks were set orally or sent by e-mail to the technical director by a list, and he had already redistributed tasks to programmers. And due to the fact that the production was remote (some of the developers were in another city), the technical director reformulated the tasks and sent them directly to the programmers.

As a result, we encountered the following problems:

• There was no real understanding of what is now at work, what tasks are being performed, what is being done and what has been done.
• It was impossible to get feedback.
• If suddenly someone fell ill or quit, they had to restore a huge chain of letters and find out: what was at work, at what stage, what was done.
• The process of coordination and clarification of additional requirements for the task took a lot of time.
• Small tasks were often postponed until later and completely forgotten.
• Checking completed tasks was also ineffective. The result of the implementation came in a few hours.
• The history of changes made by corrections and improvements was simply unrealistic to put together.

So it was impossible to work more. And we decided that it was time to move to a higher level of work on projects.

Bug tracking system selection

What goals we pursued:

• Reduce the chain of passage of the task from the initiator of the task (manager to the final executor).
• In this case, all clarifying questions, if necessary, should be discussed directly between the performer and the initiator of the task.
• At any time, get a cut on the status of completed and current work
• Save the history of work on the project, including all the work and improvements
• Monitor project time
• Prioritize tasks
• Analyze project data

We have been looking for and choosing a system for a long time. As a result, we stopped at a free and fairly well-known BugZilla bugtracker.

Bugzila was originally sharpened by software development and error logging. We did not rename the default buggy names and found that:

• Product is a project
• Section - includes projects. We divided the projects into logical groups: in work, completed, in support, promotion.
• Component is a stage: concept, design, layout, programming
• Error is a task or a bug.

We began to use the system much more widely:

• Not only errors in projects were added to it, but also tasks to be set in work: tasks in design, layout, filling, etc. Those. all workflows are fixed in BugZilla
• Time management system for performers. The time of work on the task is fixed in BugZilla. At the end of each month, a cut of the hours worked is done and, taking this into account, wages are charged (this was entered later).
• Reporting system for clients whose projects are developed according to flexible methodologies. They can always log in, see what is being done. Set a new task or change priorities, as well as give the necessary comments to the questions raised on certain tasks.

By reducing the number of intermediate performers between the formulation of the task and its execution, we increased the speed of processing user requests tenfold, thereby increasing customer loyalty and relieving managers of unnecessary work.

Differentiation of access rights to projects

The implementation of the system took place in several stages:

1. Implementing the system among a limited number of employees and debugging interaction
2. Involvement of all employees at all stages of the production process
3. Access to the system of third-party developers and clients

About the first and second steps will not tell. Information on the initial setup and work with bagzila is complete (if the habr readers will still be interested in how we did it, then write your wishes in the comments - I will write).

And I will talk about stage 3 and how to properly configure the bagzilu so that third-party developers, managers and clients can be put into it. But at the same time to prohibit third-party developers to see the already set errors on the project and not to have access to the company's projects at all.

For a long time, we used the bugtracker only within the company, and did not think about differentiating access rights to projects. There were admins who could start new projects and new users. And there were users who could set tasks, edit them and affix execution status.

Since bugzilla is mainly used to support Open Source projects, the default principle applies to it - which is not forbidden explicitly - is allowed (that is, the default settings are configured this way). Those. When you create a new task or project - it automatically becomes visible to everyone.

We were faced with two main tasks:

1. Differentiate access to projects and tasks that have already been created.
2. When creating a new project, automatically deny access to it to all users in the system. Allow administrators to choose who this project will be available.

You can adjust the distinction in different ways, I will tell you how we did it.

Differentiation of rights to already created projects:

1. Since we have a design development, then for each new project, a corresponding product is introduced in the bugtracker.
2. Each project we created a group that matches the name of the project. This is done in the section “Administration” -> “Groups” - “Create a Group”
3. In the properties of each project, we configure access settings (“Administration” -> “Products” -> Select a product -> “Access rights by groups”)
4. We expose access to the groups for the product. In order for the errors of this project to be available only to the members of the created group, set the parameters as shown in the figure: for “Group” -> “Enabled”, “Others” -> “Forbidden”. For the rest of the groups we put “Forbidden”, “Forbidden” everywhere.
5. To the corresponding users in the section “Administration” -> “Users” we select the necessary user and in the column with groups called “Included in groups” we assign the appropriate group (project) all the tasks for which the user should see.
6. Let's also prevent users from seeing all products in a search that are denied access. To do this, make sure that in the settings of the system “Administration” -> “System Setup” -> section “Group access rights” -> the parameter “useentrygroupdefault” is selected as “On.”
7. Now it is necessary to have previously introduced errors related to the project, also contact the relevant group and thus close them from prying eyes:
   - Go to the search
   - Choose a product
   - We select all errors on it (new, closed, executed, etc.)
   - Select group editing
   - Select all
   - At the very end, select "Add errors to this group" - the name of our created group for the project
   - Save
   

Now, next to every mistake we have a lock. This means that this error will be visible only to those who are allowed access.

By the way, there is no need for each programmer or designer to assign each time a group of the project on which he will work. If, as an executor, the task is not assigned to him, then he will see a specific task for this project.
To do this, you need to make sure that in the settings of the System “Administration” -> “System Setup” -> the section “Group access rights” -> the parameter “strict_isolation” is selected as “Off”. Thus, different performers can work on the same project and not see each other’s tasks, while the manager will see the full picture of the project.

Now let's see how to make new projects created and errors / tasks created for them, by default inaccessible to anyone.

1. Set in the settings of the system “Administration” -> “System Setup” -> the section “Group access rights” -> the parameter “makeproductgroups” is selected as “On”
2. Now when creating a new product, a group will automatically be created for it.
3. That's all. Now, when creating errors for this project, they will be available only to those users who are assigned the group of this project.

In order for an error / task to become accessible to all, it is necessary to remove the group membership parameter in the task properties.

Conclusion

And after 2.5 years, I can say that the decision in favor of BugZilla was made right. Now without this system neither managers, nor developers, nor clients can do. Now it is one of the main tools when working on projects. At any time, you can make a cut on the selected developer and see what he has in the work. Thereby planning to load the developers and the sequence of problem solving.

Oleg Demyanov
Web Development Manager
Twins