deploy: 4fd801c

blb/organizational/.buildinfo

@@ -0,0 +1,4 @@
+# Sphinx build info version 1
+# This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
+config: 78f3b8ace8693fed6b8ce95aee80f275
+tags: 645f666f9bcd5a90fca523b33c5a78b7

blb/organizational/_sources/index.rst.txt

@@ -0,0 +1,31 @@
+.. Phoebus documentation master file, created by
+   sphinx-quickstart on Thu Sep 26 15:18:20 2024.
+   You can adapt this file completely to your liking, but it should at least
+   contain the root `toctree` directive.
+
+Phoebus: Performance portable GRRMHD for supernovae, mergers, and more
+======================================================================
+
+`Phoebus`_ is a performance portable general relativistic neutrino radiation magnetohydrodynamics code built upon the `Parthenon`_ adaptive mesh refinement framework.
+
+.. _Parthenon: https://github.com/parthenon-hpc-lab/parthenon
+.. _Phoebus: https://github.com/lanl/phoebus
+
+Key Features
+^^^^^^^^^^^^^
+
+* Finite volume GRMHD
+* Neutrino transport
+* GR...
+* fill out
+
+.. note::
+
+   These docs are under active development.
+
+.. toctree::
+   :maxdepth: 1
+   :caption: Contents:
+   :glob:
+
+   src/*

blb/organizational/_sources/src/code_of_conduct.rst.txt

@@ -0,0 +1,76 @@
+Code of Conduct
+=====================================
+
+The community of participants in open-source relativstic astrophysics
+projects is made up of members from around the globe with a diverse set
+of skills, personalities, and experiences. It is through these
+differences that our community experiences success and continued growth.
+We expect everyone in our community to follow these guidelines when
+interacting with others both inside and outside of our community. Our
+goal is to keep ours a positive, inclusive, successful, and growing
+community.
+
+As members of the community,
+
+-  We pledge to treat all people with respect and provide a harassment-
+   and bullying-free environment, regardless of sex, sexual orientation
+   and/or gender identity, disability, physical appearance, body size,
+   race, nationality, ethnicity, and religion. In particular, sexual
+   language and imagery, sexist, racist, or otherwise exclusionary jokes
+   are not appropriate.
+
+-  We pledge to respect the work of others by recognizing
+   acknowledgment/citation requests of original authors. As authors, we
+   pledge to be explicit about how we want our own work to be cited or
+   acknowledged.
+
+-  We pledge to welcome those interested in joining the community, and
+   realize that including people with a variety of opinions and
+   backgrounds will only serve to enrich our community. In particular,
+   discussions relating to pros/cons of various technologies,
+   programming languages, and so on are welcome, but these should be
+   done with respect, taking proactive measure to ensure that all
+   participants are heard and feel confident that they can freely
+   express their opinions.
+
+-  We pledge to welcome questions and answer them respectfully, paying
+   particular attention to those new to the community. We pledge to
+   provide respectful criticisms and feedback in forums, especially in
+   discussion threads resulting from code contributions.
+
+-  We pledge to be conscientious of the perceptions of the wider
+   community and to respond to criticism respectfully. We will strive to
+   model behaviors that encourage productive debate and disagreement,
+   both within our community and where we are criticized. We will treat
+   those outside our community with the same respect as people within
+   our community.
+
+-  We pledge to help the entire community follow the code of conduct,
+   and to not remain silent when we see violations of the code of
+   conduct. We will take action when members of our community violate
+   this code such as contacting a Maintainer (a list of emails of
+   current Maintainers is made publicly available) or talking privately
+   with the person.
+
+This code of conduct applies to all community situations online (to
+include Github Issues, Pull Requests and any communication therein as
+well as Slack, Mattermost, and similar online communication platforms)
+and offline, including mailing lists, forums, social media, conferences,
+meetings, associated social events, and one-to-one interactions.
+
+Any related activity or project organized by members of the ``Phoebus``
+community, including affiliated packages, are welcome to have their own
+codes of conduct, but agree to also abide by the present code of
+conduct.
+
+--------------
+
+This Community Code of Conduct was adapted from the `Astropy Community
+Code of
+Conduct <https://www.astropy.org/code_of_conduct.html#:~:text=We%20pledge%20to%20treat%20all,nationality%2C%20ethnicity%2C%20and%20religion.>`__
+available under a `Creative Commons Attribution 4.0 International
+License <https://creativecommons.org/licenses/by/4.0/>`__. The above
+Code of Conduct was modified for use as part of ``Phoebus``.
+
+Parts of this code of conduct have been adapted from the PSF code of
+conduct.

blb/organizational/_sources/src/contributing.rst.txt

@@ -0,0 +1,88 @@
+Contributing
+=============================
+
+For the purpose of our development model, we label *Contributors* or
+*Maintainers* of ``Phoebus``. Below we describe these labels and the
+process for contributing to ``Phoebus``.
+
+Becoming a Contributor
+----------------------
+
+We welcome contributions from scientists from a large variety of
+relativistic astrophysics. New users are welcome to contributions to
+``Phoebus`` via the *Contributors* process. Contributors with 6 merged
+pull requests into the ``main`` branch (over a minimum of 6 months) will
+be eligible to join as a *Maintainer* of ``Phoebus`` with additional
+repository access and roles. However, final approval of *Maintainer*
+status will require a unanimous approval by vote by existing
+*Maintainers*, a necessary step to ensure the safety and integrity of
+the code base for all users of ``Phoebus``.
+
+The *Maintainers* of ``Phoebus`` consist of the original developers of
+the code and those that have a demonstrated history in the development
+of ``Phoebus`` prior to the implementation of the *Development Model*
+described here. Maintainers hold admin access, serve consistently as
+reviewers for pull requests, and are in charge of the maintaining,
+deployment, and improvement of efforts towards: regression testing,
+documentation, science test cases (gold standards), and continuous
+integration.
+
+To maintain their active status as Maintainer, all members will agree to
+adhere to our Community Code of Conduct and sign a Memorandum of
+Understanding described `here <GOVERNANCE.md>`__.
+
+Contributing to ``Phoebus``
+-----------------------------
+
+**Contributors**: (process for most users of ``Phoebus``)
+
+1. Create a new fork of ``main`` where your changes can be made.
+2. After completing, create a pull request, describe the final approach
+   and ensure the branch has no conflicts with current Regression Tests
+   and Formatting Checks.
+3. Assign external reviewers (a minimum of 1, one of which should be a
+   Maintainer, and which cannot be the contributor). Provide concise
+   description of changes.
+4. Once comments/feedback is addressed, the PR will be merged into the
+   main branch and changes will be added to list of changes in the next
+   release.
+5. At present, Releases (with a git version tag) for the ``main`` branch
+   of ``Phoebus`` will occur at a 6 to 12 month cadence or following
+   implementation of a major enhancement or capability to the code base.
+
+*Maintainers* of ``Phoebus`` will follow the same process for
+contributions as above except for the following differences: they may
+create branches directly within ``Phoebus``, they will hold repository
+admin privileges, and actively participate in the technical review of
+contributions to ``Phoebus``.
+
+List of Current Maintainers of ``Phoebus``
+------------------------------------------
+
++-------------------+--------------------------------+-----------------------+
+| Name              | Handle                         | Team                  |
++===================+================================+=======================+
+| Brandon Barker    |                                | Los Alamos National   |
+|                   | `@AstroBarker <https://www.g   | Lab                   |
+|                   | ithub.com/AstroBarker>`__      |                       |
++-------------------+--------------------------------+-----------------------+
+| Josh Dolence      | `@jdolence <https://ww         | Los Alamos National   |
+|                   | w.github.com/jdolence>`__      | Lab                   |
++-------------------+--------------------------------+-----------------------+
+| Carl Fields       |                                | University of Arizona |
+|                   | `@carlnotsagan <https://www.gi |                       |
+|                   | thub.com/carlnotsagan>`__      |                       |
++-------------------+--------------------------------+-----------------------+
+| Mariam            | `@mari2895 <https://ww         | Niels Bohr Institute  |
+| Gogilashvili      | w.github.com/mari2895>`__      |                       |
++-------------------+--------------------------------+-----------------------+
+| Jonah Miller      | `@Yurlungur <https://www       | Los Alamos National   |
+|                   | .github.com/Yurlungur>`__      | Lab                   |
++-------------------+--------------------------------+-----------------------+
+| Jeremiah Murphy   |                                | Florida State         |
+|                   | `@curiousmiah <https://www.g   | University            |
+|                   | ithub.com/curiousmiah>`__      |                       |
++-------------------+--------------------------------+-----------------------+
+| Ben Ryan          | `@brryan <https://             | Los Alamos National   |
+|                   | www.github.com/brryan>`__      | Lab                   |
++-------------------+--------------------------------+-----------------------+

blb/organizational/_sources/src/governance.rst.txt

@@ -0,0 +1,137 @@
+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 active status as a User, Contributor, or Maintainer,
+all members will agree to adhere to a Code of Conduct.
+
+Memorandum of Understanding
+---------------------------
+
+In addition to our Community Code of Conduct, all code Maintainers will
+sign a memorandum of understanding (MoU) that will describe general
+expectations and responsibilities. The MoU that will serve as part of
+the ``Phoebus`` Community requires the following:
+
+-  Maintainers will uphold and exemplify the *Development Model*
+   outlined as part of the ``phoebus`` Community described
+   `here <CONTRIBUTING.md>`__.
+-  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 attend the annual
+   workshop.
+-  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 the 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 a regular developer call.
+
+| Monthly Maintainer meetings will also be an important part of ensuring
+  productivity and timeliness of the meeting.
+| 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 move forward during the next month.
+| 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. 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.