Team 5

1. Team 5 Policies

Team 5's goal is to make the overall system as Modular and Flexible as possible, while maintaining the back-end's Relevance and Stability.

To achieve its goal, Team 5 shall:

1. Ensure back-end teams don't have to worry about any other back-end teams' work. (Modularity)

One of the primary objectives of Team 5 is to help allow back end teams to operate independently of one another. Since it is Team 5 that will hopefully be putting all of these back-end modules together, it is hoped that Team 5 shall be able to handle inter-team dependencies by resolving these themselves and/or letting the respective teams know what the problem is so that it can be resolved. In doing this, the overall system is made more modular and the back-end teams can focus more strongly on their respective subjects.

2. Ensure that the back-end system is applicable to as wide an audience as possible. (Flexibility)

It is considered critical that the back-end systems be as flexible as possible. To this end, it is one of the objectives of Team 5 to ensure that the overall system does not assume that the end-user is going to be making a file browser, be it GUI or CLI based. If possible, Team 5 shall ensure that, even if the system includes functionality specifically for a file browser, the system shall also be usable by other types of programs, such as a way for saving/loading files in a larger application. It is okay to have specialized functionality, but Team 5 shall attempt to keep the system as broadly applicable as possible. This shall include coming up with ways to broaden the existing functionality of the back-end, independently of the GUI.

3. Ensure that the front-end implementation has all that it needs. (Relevance)

Though Team 5 shall try to ensure that the back end is applicable to as many situations as possible, it also must ensure that the overall project does not lose sight of its primary purpose. To that end, Team 5 shall prioritize the functionality that the front-end teams need. Team 5 shall make sure that the project neither neglects back-end flexibility nor neglects its primary purpose. Team 5 shall not allow the project's back-end teams to forsake flexibility for relevance, but neither shall it allow the project to get so engrossed by flexibility that the program never gets finished.

4. Test the system and resolve any bugs, dependencies, or conflicts. (Stability)

Though Team 5 shall attempt to allow the back-end teams to operate as independently as possible, Team 5 shall also make sure that their code works together, managing any testing that needs to be done and resolving any problems that arise. Furthermore, since it is at Team 5's API where all of the back-end material comes together, Team 5 shall test the integration of the systems components. Team 5 shall assume that the other back-end teams shall test their code internally. Because of this, Team 5 shall focus its testing efforts on the project as a whole, testing only the code the implements the other back-end modules, not the modules themselves.

It is the hope of Team 5, as it currently stands, that the teams that replace us shall focus on project integration and direction. The members of Team 5 shall try to provide feedback to other teams on the overall direction the project is taking and which direction they thing the project should be taking. This is, in part, because it is hoped that Team 5 shall be most aware of what the majority of the team is doing.

If the project leans too strongly to one of the Team 5 objectives, forsaking its opposing objective (Modularity opposing Stability and Flexibility opposing Relevance), the members of Team 5 shall attempt to re-balance the priorities of the project. While most other teams shall emphasize a depth of knowledge, Team 5 shall need a breadth of knowledge of nearly equal size.

Anyone hoping to work for this team shall be prepared for challenges of concept, not just code. Team 5 will struggle as much with where to take the project as with how to actually get it to that point. Balancing these two, general directives makes working in this team difficult and different. Expect to ask yourself, even if you want the project to work a certain way, can you get it to work that way? Conversely, even if you can get something to work a certain way, do you want it to work that way?

This caution comes from experience.