Organizational Structure

Phoebus uses a hybrid flat-and-hierarchical organizational structure.

The flat structure fosters power sharing among senior and junior members and avoids the many pitfalls of power-over dynamics. For example, in power-over structures, someone with explicit power can inadvertently, or on rare occasions intentionally, silence critical voices.

This dynamic can quickly lead to an organization overlooking inherent problems that could lead to ineffectiveness or even catastrophic failure of the team.

In contrast, our aim is to illuminate potential problems early and quickly find solutions.

This strategy also efficiently taps into the diverse wealth of knowledge of the team.

At the same time, the PI and Co-PI have financial and reporting responsibilities to their respective universities and funding agencies.

The general procedure for the hybrid structure is as follows.

The flat structure will make major decisions in direction and resources, and the PI and Co-PI will assume the responsibility for executing those decisions.

The following gives details on this hybrid structure.

Team

The founding team consists of the following: original core developers and Maintainers at Los Alamos National Lab, Jeremiah Murphy at Florida State University, and Carl Fields at University of Arizona.

Since, an objective of Phoebus is to grow the developer and user base, the Phoebus Project will have an explicit mechanism for adding new members. There are three categories for Phoebus members: maintainers, contributors, and users.

User: As open-source software, anyone may download, compile, and execute Phoebus. New users will encouraged to join communication channels for connection with the larger Phoebus community.

Contributor: Users who wish to contribute to Phoebus may do so following our Development Model for new users. These changes will be integrated into the main branch of the code upon approval. Consistent contributions also provides the opportunity for Contributors to be eligible to join as a Maintainer, the final approval of which will require a vote.

Maintainer: These are the core team who have “merge” permissions on the repo and are working to keep the code sustainable long term.

To maintain their relevant active status, all members must make a food faith effort to maintain a supportive, productive environment.

Memorandum of Understanding

In addition to our Community Code of Conduct, we ask that maintainers especially keep the following suggestions in mind to help facilitate an efficient and welcoming collaboration:

• Maintainers should uphold and exemplify the Development Model outlined as part of the phoebus Community described here.

• Within reason, maintainers will make a good-faith effort to attend team meetings. In an effort to accommodate the dynamic schedules and availability of many of the core team of Maintainers, coordination efforts will be made to ensure that at least 1 Maintainer is present for all meetings.

• Maintainers will make a good-faith effort to monitor the fraction of the meeting time that they speak. The meeting time is limited, and several people may have something interesting to say, report on their updates, or contribute constructive arguments. One should be self-aware and notice if one is dominating conversations, and attempt to make a conscious effort to include other voices and perspectives in the discussion.

• Maintainers consider it their responsibility to voice their questions and/or concerns as early as possible. This will ensure that the organization addresses concerns rapidly and effectively.

• Maintainers consider it their responsibility to listen and understand questions or concerns raised by other partners or through concerns communicated through email to individual Maintainers.

Approval by Vote:

Many of the decisions in the organization will be enacted after an approval by majority vote of active Maintainers. The process of listening and adjusting strategies to meet everyone’s needs is vital for power-sharing organizations.

Importantly, spending a little time up front to listen and resolve concerns reduces the pain and time spent later in intense conflict resolution.

Communication and Connection:

To facilitate open and effective communication, the Phoebus will offer multiple levels of communication. Developers will communicate via email, GitHub, and a Phoebus Slack channel.

To respond to user inquiries, the Phoebus Project will host a mailing list via Google or similar.

To maintain a standing record of user inquiries and responses, we will post the inquiries and responses on a public-facing site.

All Maintainers will have the option to respond to the inquires; to ensure that someone is responsive to the user inquiries, the team will triage tickets/questions in developer meetings.

Subject to availability, monthly Maintainer meetings will also be an important part of ensuring productivity and timeliness.

Each meeting will last up to 60 minutes. We will assess and discuss the goals from the previous meeting.

In particular, we will take note which goals were completed and which were not. If there are uncompleted goals, we will assess why they were not completed. Next, we will discuss the goals for the upcoming month, quarter, and year.

We will decide which goals to prioritize.

All of this will be recorded on an online document which will be available to all Maintainers.

Each meeting of the core Maintainers will be managed by a meeting manager.

The primary job of the meeting manager is to: 1) gather a list of agenda items for the next meeting, 2) ensure that the meeting runs on schedule, and 3) ensure equitable participation by all participants.

Again, in keeping with power-sharing, the meeting manager position will rotate among the core Maintainers, even junior members.

Note

We maintain some flexibility in the cadence and structure of meetings, in particular, in periods of low activity, meetings may be skipped or held in a less formal manner. We recognize that the availability of maintainers is contingent upon many factors.