1. Warrior Project Organizational Structure

Figure 1: Warrior Project Organizational Structure

1.1. Warrior Governance Team

Warrior Governance Team (WGT) is made up of Project Leader (PL) and Technical Steering Committee (TSC). The Warrior Framework project is governed by the Benevolent Leader (BL) model. The project leader and the Technical Steering Committee act as the BL for the project. The benevolent leader (BL) model require that the final decision-making authority rests with one person, who, by virtue of personality and experience, is expected to use it wisely. The role of the benevolent leader is more of a community arbitrator or judge that should be reluctant to make decisions by a mandate. As a general rule the BL do not make most of the decisions. They are expected to work out decisions through discussion and experimentation whenever possible. If consensus cannot be reached, someone has to guide the decision so that continuous improvements can proceed.

1.1.1. Project Leader
Fujitsu Network Communications (FNC) is leading the project and serves as the arbiter for the project. The FNC appoints a representative to act as the project leader and execute the project leadership activities on a day-to-day basis. The project leader makes appointments to technical steering committee roles and is responsible to set the direction for the project to grow with continuous improvements.
Brian Jishi ( is the project lead appointed by FNC.

1.1.2. Technical Steering Committee
The Warrior Framework project will be governed by a Technical Steering Committee, which is responsible for high-level technical guidance of the project. The TSC has the final authority over and the responsibility for this project including:

• Setting Technical direction,
• Governing the Project,
• Overseeing community management and policies,
• Setting up merit based system for project roles,
• Researching new technologies that Warrior project can benefit moving forward,
• Setting Project guidelines,
• Branding, licensing, domains, and trademarks,
• Overseeing all assets of the project including the project website and Github repositories,
• Securing the intellectual property generated by the Warrior Project.

Membership in the TSC is expected to evolve over time according to the needs of the project.

1.2. Warrior Community
Everybody is welcome to contribute to the project. Known issues are posted with skill level and time commitment requirements. Contributors who want to provide a resolution to an existing issue are able to choose the right task by considering the role they would like to play, the skill level and the time commitment that they can volunteer to complete the task. Contributors build their skill levels by having tasks completed in the project over time. A contributor can report an issue and/or propose an improvement in any part of the project. These reports and proposals are processed and posted as appropriate. First time contributors are expected to choose a manageable piece to contribute and follow up with the feedback. A contributor may take any one of below roles:

• Release Manager
• Documentation Manager
• Issue Manager
• Code Moderator
• FAQ Manager
• Communications Manager
• Committer
• Reviewer
• Tester
• Author
• Developer

1.2.1 Release Manager
The release manager has final say over what changes will be included in a particular release. Release manager also manages the patches that are covered by the release and makes sure that all patches are assigned to a developer and these patches reach to a stable state. To make decisions, the release manager may choose to facilitate discussions within the project community; however, the community grants the release owner sufficient authority to make final decisions. After successful completion of bug-fixes (patches), improvements, and new features that are planned to be in the release, the release manger is responsible to merge the release branch in to master branch and tag with a release name.

1.2.2. Documentation Manager
Documentation manager makes sure that any new feature or improvement including the bug-fix will have the code documentation and project documentation that feeds into the user guide. The documentation manager also manages and organizes the potential documentation contributors (Authors) from the community to ensure that the documentation changes are complete and handled appropriately. The documentation contributions may be in the form of new items or corrections/improvements in the existing documents.

1.2.3. Issue Manager
Issue managers monitor what goes into the issue tracking database, aggregate these problems by filtering duplicates and remove obsolete tickets. Issue managers prioritize these filtered issues and classify them into patches, bug-fixes, hot-bug-fixes, new features, and improvements. They post the issue with the role, skill level and time commitment requirements attached to it. They may also make suggestions who could be a good candidate for an issue based on a contributor’s subject matter expertise in the project. They track the ownership of the issue to a particular contributor and push into a release. Issue managers are familiar enough with the contributors’ expertise and skill levels, so that they can bring an issue to a certain contributor’s attention, if needed. They are familiar with the future release schedule and its target milestones, so that they can assign the issue to an appropriate future release where it makes sense the most. However, these milestones for each release are moving targets and may change as more bugs are reported with varying priorities. To this end, issue mangers may shift issues between releases to keep them manageable, but make sure that an acceptable technical resolution is reached for each issue.

1.2.4. Code Moderator
Code Moderators step in only when there is a dispute between the reviewer and code contributor. They settle the dispute with technical evidence.

1.2.5. FAQ Manager
FAQ managers handle all FAQs by receiving help from subject matter contributors that focus on that specific question. The FAQ managers also capture FAQ contribution from community who provide and/or make suggestions for the FAQ section and provide a resolution for these contributions.

1.2.6. Communication Manager
Communication manager monitors the list(s) and forum(s) and arbitrates the topics to subject matter contributor and makes sure that all requests are handled within the code of conduct rules and brought to a resolution.

1.2.7. Committer
Committers check the reviews of a Pull Request in a more holistic view and make sure that the new additions will not break the project somewhere else in the code base. They then perform the final commit to the development branch.

1.2.8. Developer (Code Contributor)
Developers contribute code for bug-fix, new-feature, and/or improvement. They are responsible for providing documentation for the changes and/or inclusions into the code base. They also provide test files for the code review and are expected to address any concerns raised by the reviewer and work with a moderator in case any dispute arises.

1.2.9. Reviewer (Code Review Contributor)
Code reviewers examine the code that is submitted to the project by a Pull Request and has passed the regression testing. A reviewer provides feedback to the developer, if there are concerns with the code. Any concern raised by the reviewer is expected to be addressed by the developer with in an acceptable amount of time. The reviewer accepts the code after all concerns are resolved.

1.2.10. Tester (Code Test Contributor)
Testers make sure that all tests are performed and cleared for a code that is added or changed in a particular release. Testers also perform all necessary tests to verify the stability of the release. Any bugs found during the release testing would be assigned by the tester to the concerned developer and the fix would be delivered to the release branch.

1.2.11. Author (Documentation Contributor)
Warrior Framework project expects developers to be the author of their contributions by providing their code documentation and project documentation that feeds into the user manual. However, authors without being a developer are welcome to contribute to other non-code related project documentation including additional guideline documents, release documentation, and tutorials.