The TyBugs software uses a number of terms with specific meanings. These meanings are discussed here.
User
A user represents a single real person in the TyBugs system. While it is possible for a real person to have more than one TyBugs user account, this is generally unnecessary since a single user can belong to multiple project teams. It is usually not an efficient workflow to have ‘virtual’ users with no corresponding real person, since any tasks assigned to this user would not have anyone clearly responsible for processing them.
Users are created during the initial login process and are generally self-managing. Users may be invited to one or more user groups and this may grant them privileges as a member of that group. Once the user leaves the user group (voluntarily or otherwise) they lose any privileges granted to them via their membership of the particular group, but retain any privileges granted to them through other users groups of which they are a member.
Users are referred to by their unique username. The term “<nobody>” is sometimes used in the place of a username, and refers to no user. The term “<unknown>” is used in a field when the viewer does not have sufficient privileges to determine the actual user.
User Group
A user may belong to zero, one, or many user groups. Any user can create and administer their own user group. The owners of a user group may invite other users to join their user group. They may also remove users from their user group. Being a member of a user group does not confer the group owners any powers of the member’s user account.
A typical project will have a small number of user groups, such as “Project External Testers”, “Project Staff”, and “Project Admins”. Typically the “Project Admins” group will own all of these groups and will be responsible for TyBugs administration such as creating new groups, inviting or removing users from groups, etc.
A user group grants its members visibility of some number of branches.
User groups are typically referred to by their name, however the uniqueness of this name is not enforced. TyBugs will not become confused between user groups with an identical name, however project users and administrators could easily become confused so this should generally be avoided.
Branch
Branches typically represent particular products (or product versions) which are created by the project, although they may also represent other concepts such as specific duties or visibility such as “Build Requests”, “Web Team”, or “Internal Requests”.
Any user may create a branch, however the branch is only visible to that particular user until the user attaches the branch to one or more user groups. The branch then becomes visible to all members of those user groups. The user must have edit permissions on both the user group in question and the branch in order to attach a branch. For this reason, only project administrators will typically create branches.
Branches are typically referred to by their name, however the uniqueness of this name is not enforced. TyBugs will not become confused between branches with an identical name, however project users and administrators could easily become confused so this should generally be avoided.
Task
A task is a single unit of work. In ideal terms, each task is broken down into its smallest components. If a task is created which is comprised of numerous smaller components, then appropriate sub-tasks should be created as dependencies. This is not always the role of the person entering the task- they may be defining overall strategy, or filing a feature request or bug report- but the task should be fully broken down before any work begins, and ofter before the task is assigned to the person carrying out the work. In such a case, a team lead might assign the parent task to themselves and the dependencies to their various team members. This allows the team members to work on the task according to their own schedules, and the team lead can follow up on the overall progress and sign off on the final result.
Any user may create a task, however the task is only visible to that particular user until the user adds one or more branches to the task. The user needs visibility of the branch in order to add it to the task, but does not require edit privileges on the branch. Once branches are assigned to a task, other users who have visibility of those branches can also see (and perhaps edit) the task.
Schedule
The TyBugs software provides scheduling tools with two primary functions: to allow individual users to determine the order in which they should tackle their tasks, and to allow managers to estimate completion dates for tasks and projects. The scheduling tools are forward-looking, meaning that they consider the best path forward from the tasks available at the current time. Significant changes to the available tasks, priorities, and dependencies will be rapidly reflected in the scheduling output. This differs from traditional tools such as Microsoft Project which provide a more static view of the project, based on expectations formed at the creation of the project schedule.
While the “living schedule” is a sensible workflow even within Microsoft Project, it is not the default behaviour in such a system. In TyBugs, it is the only possible behaviour. Any changes to the actual work tasks assigned to users have an immediate impact on the entire project schedule, whether these be changes for the good- such as completion of a task, or changes for the worse- such as failure to complete a task on time, or the addition of new tasks. The project manager’s role thus changes from “ensuring that the schedule reflects the actual state of the project” to “ensuring that the schedule continues to meet our target objectives.”
Any user may create a schedule, however the schedule is only visible to that particular user until the user attaches the schedule to one or more user groups. The schedule then becomes visible to all members of those user groups.
A given user may have visibility of multiple schedules, however they only view data from a single schedule at a time. The user may edit their own user details to select which schedule they are working with. Some task properties such as estimated duration, priority, start and end date, etc. are actually functions of the schedule and will show different values depending on the user’s selected schedule (or no values if they have no schedule selected.)