Contribution and Project Operating Procedures

The purpose of this page is to:

  1. Provide an introduction to contribution.
  2. Provide a brief overview of the scope of work.
  3. Answer a few frequently asked questions about contribution to the project.
  4. Provide an overview of the working group standards development process.
  5. Detail the standard operating procedures of the project.


Every day, thousands of individuals and teams all over the world apply effort toward this common direction. Contributors to The Auravana Project are here to integrate their discoveries and efforts into a unified specification standard that details the logical derivation, the formal development, and guided operation of a community-type society.

Auravana project is contributed to by an intrinsically motivated team of dedicated individuals working toward this common direction. We are inviting anyone interested in joining us in our mission to live and create for the highest fulfillment of all. Operationally speaking, we participate on this project in a self-directed, collaborative, and integrated manner. As individuals, we contribute where we have an interest and the necessary skills. If you have an interest, but do not have the skill set necessary to advance the project along the lines of your interest, then as you work toward developing skills in your area of interest,  your learning and skill development may be exactly what is needed to advance a less developed (or possibly, errored) area of the project. Sometimes it is easier for a learner to spot gaps, contradictions and errors in an existing design than it is for a “professional” to notice those same issues.

Please note that we are open-source and free-sharing everything needed for duplication of each component and/or all of a community-type society. Everything we do is added to our online platform without patents, copyrights, or limitations of use of any kind. This means everyone is welcome and encouraged to use anything we create in any way they like. We are designing a scalable and duplicable societal system (and city systems therein) that could transform the planet within ten years. If we design a city for a thousand people and the technology and systems in the community could duplicate the city and itself every 6 months we could house 10 billion people in approximately 10 years or 20 duplications. Join us in this effort.

Lots of open source contributors start by being users of the system they contribute to. When you find a bug in an open source system you use, you may want to look at the source to see if you can solve it yourself. If that’s the case, then contributing the solution back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it. If you want to contribute, but are unsure of where go, start by thinking about the projects you already use, or want to use. The projects you’ll actively contribute to are the ones you find yourself coming back to. Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct.

Besides contributing directly to Auravana, if you want to take an active role in making this world a better place through further development of our common direction, then there are many ways you can help. Firstly, there are other project working on this direction that may be more aligned with your area of interest. Secondly, below are a few of the ways you cam become involved in this direction and support Auravana:

  • Conduct scientific research and share your research with us.
  • Read the standards and send us your significant additions or corrections.
  • Share the ideas conveyed by the project with others to stimulate interest.
  • Network with others in an effort to find individuals with skill sets / interests that we may be missing, but are essential to the successful completion of the project.
  • If you are a student, then use the flexibility of course assignments to complete work/tasks that advance this project. If you are enrolling in a college or university then select courses and assignments that advance this direction. Contact us if you are interested in determining useful class assignments as project deliverables.

2. Scope of work to be completed

Simplified project timeline for a community-type society

Please note that this is a simple scope of work and provides an overview of the project mid-term deliverables. The full project work list is located in the current Project Plan.

Our present sub-projects (and sub-project teams) include:

  1. Societal standards working groups (societal engineering development team)
    1. Update standards continuously with an annually published revision.
    2. Continued development and error correction of the existing standards. This includes integration of a continuous ‘literature review’ into the standards.
    3. The existing standards are:
      1. The System Overview Standard
      2. The Project Plan Standard
      3. The Social System Standard
      4. The Decision System Standard. There are two principal parts to the decision standard:
        1. The written documentation part.
        2. The software system part, including all mathematical modeling and software programming. The mathematical modeling and software programming of the decisioning system.
      5. The Lifestyle System Standard
      6. The Material System Standard. There are four principal parts to the material standard:
        1. The written documentation part.
        2. The architectural CAD- and BIM-based drawings for the integrated city system.
        3. The 3D visually modeled representation of the integrated city system (with different configurations).
        4. Integration of the 3D representation into a gaming engine for virtually simulating all technical operational aspects of the community.
      7. All standards together can be combined into a societal and city simulation – an open source virtual reality simulator of the city for societal engineering and marketing purposes.
  2. Project coordinator team (societal project coordination team)
    1. This team is composed of all project coordinators.
    2. Coordinators are points of contact for working group members and perform integration and synchronization tasks for the project.
    3. This team organizes an annual conference/event for the whole working group team and between organizations/projects that share this similar direction to analyze, integrate, refine and refinalize the most up-to-date version of the standards.
    4. This team continues development of the project’s (i.e., organizations) operational procedures and website to ensure accuracy with the evolving standards.
  3. Project orienting team (societal on-boarding team)
    1. This team conducts screening, orientation, and administration activities for working group members (a.k.a., onboarding, etc.).
      1. Value screening questionnaire and documentation for entrance into the community once it is constructed. This is a proposal for an entirely different way of living with a value orientation highly divergent from the many other orientations seen throughout modern society. Entrance into the first city will depend highly upon the value orientation and abilities of the individual. The project will screen individuals to ensure that their value orientation and abilities are aligned with those of a community-type society.
      2. Orienteering guidebook to simply understanding, facilitate behavioral change, and provide appropriately relatable community life-case (i.e., user case) events.
    2. Continued development of the website and useful perception orienting content.
  4. Relationship development team
    1. Adaptation of the standards for relationship development:
      1. An oral narration of the standards (i.e., turning them series of audio/video presentations). Note that this is challenging because the standards are “living” documents and republished annually.
      2. Creation of video media detailing the specifics of the proposal through a series of professional videos for both marketing and learning purposes. Descriptive video media of the standards presented in a professional, personal, and visually appealing manner.
      3. Usage of an open source virtual reality simulator of user cases it community cities.
    2. A fictional story (i.e., novel) of someone’s life in community (in the not too distant future so that it is relatable). This should not be distant science fiction, but portray a short-term view of the lifestyle of individuals among community and the community’s operation.
    3. A high-budget movie.
    4. A board game as a learning and sharing tool.
    5. Interview podcasts. These serve two purposes: 1) To remove contradictions and fill in the gaps in our proposal through discussion with others. 2) To facilitate in sharing of the system and possibly get others involved. Podcasts and interviews with others who could facilitate the evolution of the specifications and with whom a relationship would be useful for the formation of the community network.
  5. State interface team
    1. The jurisdictional and geopolitical analysis.
      1. A comprehensive jurisdictional and geopolitical analysis to determine possible locations for placement of the first community on this planet with comparison between locations and a feasibility/viability determination. Herein, there is a requirement for the establishment of relationships in the geo-jurisdictional area where the community has a probability of placement.
  6. Market interface team
    1. The business plan
      1. A business plan and accompanying analysis to ensure the continued financial viability of the community within the larger monetary market. The first version of the community [at least] will require significant resources from the market, and hence, the community will require some balance of [angel] donations and business interaction. The Community will have to interact with the market [to some degree], and this will have to be planned and accounted for.

3. Frequently asked questions about contribution to the project

  • Q. Is there an application process?
  • A. No. There is no application process at the present time; you are either participating through your contributions or you are not.
  • Q. What do we do on a daily basis? In other words, what would it look like if “I” where to participate in this project.
  • A. We complete tasks along the lines of our project plan (i.e., scope of work) toward the design and development of the first community of this kind. It is important to note that when we communicate as participants to this project, we focus on “tangible contribution” items and activities that maximize our forward movement toward the completed design and eventual establishment of the proposed community. “Tangible contribution” refers to work directly related to the project’s identified action items. We focus on tangible items and activities to maximize our energies, effort expenditure, and productivity as participants to this project.
  • Q. I am interested in participating, but I would first like to know what the project’s purpose, goals, and core values are.
  • A. Our overarching purpose, goals, and values are detailed at length in the System Overview, Project Plan, and Social System standards (they are also referenced within the other standards). Please see the table of contents of the two specifications for location. Some of this content is also noted on our ‘About’ webpage.
  • Q. Do you accept financial contributions?
  • A. No. Members may pay into an escrow account to pay fees on platforms required to efficiently operate the project.
  • Q. I am interested in founding the first community.
  • A. Please tell us what resources you are able to contribute.

4. Working groups develop the standard

A technical working group develops the standard. Teams implement the standards. Sometimes, the working group that develops the standard is also called a team.

The core technical working group that develops the whole standard is divided into working sub-groups by articles within the Standard, or by situational relevant topic.

To contribute to a working group:

  1. Join a working group and work as a core member of the working group.
  2. Send additions, corrections and edits to a working group member.

Join a technical working group

Technical working groups are groups of people (and technical systems) working together to develop and update articles within the unified societal specification standard. Project coordinators coordinate member activities such as technical meetings, publishing/ committing, and administration.

Project Auravana organizes the development of a set of core open source standards through a set of functional working groups. As a coordinated participant on a working group, there are requirements:

  1. Use an internal chat-discussions to evolve the article.
    1. To evolve the article by completing all known associated tasks.
  2. Meet formally once a month:
    1. To help each other resolve open source issues.
    2. To integrate work completed separately.
    3. Interview experts.
  3. Meet formally annually to:
    1. To help each other resolve open issues.
    2. To integrate work completed separately.
    3. To republish new revision of the unified standard.

Full members of a working group are those who are active, as demonstrated by the completion of tasks and attending formal meetings. Individuals will be removed from active status if they do not complete tasks and/or do not attend formal meetings.

Working group full members are expected to have previous domain knowledge and understanding of the subject matter, and the subject matter’s integration into the unified societal system (as currently published). There are two means of becoming part of the Auravana working group core team. The first is to become an active contributing member with previous domain experience. Show the domain experience to the project coordinator and identify a task or tasks that you will start completing. The second is to become a mentee, whose task completions are overseen and reviewed by a more experienced working group contributor. In this case, there is no requirement for previous domain experience. There is no coercion to complete tasks, but if they are not completed, then the contributor will have their role status changed to inactive. Working group members are expected to complete working group tasks. Working group members are active contributors only; if someone is not going to be active on a daily or weekly basis. An inactive role means no interactive access to chat-discussions, nothing beyond chat access to monthly meetings, and nothing beyond chat access to annual meetings.

Working group core membership:

  1. Procedure to become a working group member:
    1. Join the Auravana Project’s Slack Working Group.
    2. Join the Slack #contributor-orienteering channel. Please use your real name. You cannot join a working group if you do not use your real name.
    3. Request to apply to a working group (and/or, send your corrections).
    4. Agree to all open source Terms and Conditions via an email to the projects email address.
    5. You will be invited to a chat/interview with working group project coordinators.
      1. In the Slack channel you will be, firstly, asked to agree to all open source Terms and Conditions.
      2. You will then be asked to state that you have read and will follow the projects stated Operating Procedures.
      3. You will then be asked to state that you will be able to identify and complete the tasks of a member of the working group (and not assignment of tasks, except possibly during mentorship).
    6. After initial agreements, you can select either an immediate full working group position or a mentee position. If you can demonstrate prior competence, then you can become a full working group member.
      1. I am (or, am not) able to demonstrate prior competency?
      2. Full working group members are expected to be competent (with knowledge and skills) in their subject area, and to become a full working group member, competence must be demonstrated. In the channel, project coordinators will ask you to demonstrate experience (prior competency) in the subject matter area of the working group to which you are applying. Full working group members should have a high-level understanding of the project, the proposed society, and their subject area.
        1. As a full working group member, you will not be given tasks, you are expected to identify and to know what the tasks are for your subject area, and complete them.
      3. Mentees are expected to make mistakes and have their work double checked. In the channel, if you don’t have demonstrable experience, then request a mentee position. As a mentee, someone is available to give you tasks (if you don’t now what tasks to select yourself) and to double checks the outputs of those task.
        1. As a mentee working group member, you may be given tasks and are expected to complete them with support and guidance if needed.
    7. The project coordinators will agree the individual as a full working member, or a mentee under the oversight of someone’s who is responsible for tasking and work output. Or, the project coordinators will deny a membership because there is agreement that a potential risk is posed. The most common risk is a misunderstanding of the fundamental structure of a community-type society; therefore, taking decisions that are dis-unified with the rest of the system.
    8. If the project coordinators agree the individual as a member, then a project coordinator will change the role status of the individual to enrolled access membership position.
  2. Procedure of working group / team assignment:
    1. If interest and no prior competence, then go to supervised contributor position (if available).
    2. If prior competency, then go to working group position (if available).
    3. Position availability is dependent on not threatening or harassing (seeking to hurt) others in the working group. Position availability is also dependent on an agreement to work on an open source project. Position availability is further dependent on understanding the fundamental structure and operation of a community-type society.
  3. Working group members must maintain a situational awareness awareness of:
    1. What is expected of an understanding?
    2. How do I acquire an understanding?
    3. What must be done because of this understanding?

The open source structure of the Auravana Project

The Auravana Project Societal Standard is held in a digital, open source repository.

Working groups use the following tools to change the standard(s) within the repository:

  1. Issue tracker: Where people discuss issues related to the project.
  2. Pull requests: Where people discuss and review changes that are in progress.
  3. Discussion forums or mailing lists: Some projects may use these channels for conversational topics (for example, “How do I…“ or “What do you think about…“ instead of bug reports or feature requests). Others use the issue tracker for all conversations.
  4. Synchronous chat channel: Some projects use chat channels (such as Slack) for casual conversation, collaboration, and quick exchanges.

This open source societal project has:

  1. License (terms: By definition, every open source project must have an open source LICENSE. If the project does not have a license, it is not open source.
  2. ReadMe (about & procedures): The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
  3. Contributing: Whereas READMEs help people use the project, contributing docs help people contribute to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to.
  4. Code-Of-Conduct: The code of conduct sets ground rules for participants’ behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
  5. Other documentation: There might be additional documentation, such as tutorials, walk-throughs, or decision procedures, especially on bigger projects.

A typical open source project has the following types of people:

  1. Instantiator (author, issuing entity): The person/s or organization that created the project.
  2. Coordinator (owner, accountable control entity): The person/s who has administration control ability over the organization or repository (not always the same as the original author). For the Auravana Project, this position is held by the principal project coordinator. Coordinators have commit control.
  3. Working groups (contributing member, accountable working entity): Contributors who are responsible for driving the vision and doing the work.
  4. Teams (team member, accountable working entity): Contributors who are responsible for following through on a standard (or, set of standards). Many team members are also called technicians, because they are technically competent. The societal standard working group is also a team.
  5. Contributors: Everyone who has contributed something to the project.
  6. Users and everyone else (stakeholders): People who use the deliverables of the project or who are impacted by the project. They might be active in conversations or express their opinion on the project’s direction.
  7. Project: The totality of all effort and content/material to deliver something. The societal standard is a project with multiple sub-project including a societal standard and a materialized network of city service systems.

Contribution to the Auravana Project’s files

The Auravana Project’s files are available via the Auravana Project’s GitHub Repositories page. A GitHub repository is a directory (folder) where files and folders can exist. Other people can create their own copies of this “directory” and modify it as they wish, then request that their changes get put into the main repository.

Once you know the repository to which you will be contributing, then you need to do some first-time setup. Fork a repository to start contributing to a project. You can fork any public repository to your user account or any organization where you have repository creation permissions. The process is:

  1. Fork the repository.
  2. Make the addition/fix.
  3. Submit a pull request to the project organization. The terminology used to merge a branch/fork with an official repository is a ‘pull request’. A “pull request” is you requesting the target repository to please make your changes.
  4. Working group review of pull requests.
  5. Project coordinator commits changes [to master].

Modification of the Auravana Project files must:

  1. Meet the definition of open source.
    1. Does it have a license? Usually, there is a file called LICENSE in the root of the repository. This LICENSE is required for the market-State.

Contribution necessitates forethought. The following items are important to consider when contributing to any project’s files:

  1. Files are modified through commit activities.
    1. Look at the commit activity on the master branch.
    2. When was the latest commit?
    3. Does the project have sub-groups that resolve decisions together, and then a coordinator makes the decided commit?
    4. Are commits made on some cyclical basis (e.g., annually, bi-annually)?
    5. How many contributors does the project have?
    6. How often do people commit? (On GitHub, you can find this by clicking “Commits” in the top bar.)
  2. Project is active with issues? Note here that issues may be worked through on a platform outside of that which hosts the files; i.e., outside of GitHub, such as using Slack).
    1. How many open issues are there?
    2. Do maintainers respond quickly to issues when they are opened?
    3. Is there active discussion on the issues?
    4. Are the issues recent?
    5. Are issues getting closed? (On GitHub, click the “closed” tab on the Issues page to see closed issues.)
  3. Project is active with pull requests? Pull requests let contributors tell others about changes they have pushed to a branch in a repository on GitHub. Note here that pull-type requests may be worked through on a platform outside of that which hosts the files; i.e., outside of GitHub, such as using Slack).
    1. How many open pull requests are there?
    2. Do maintainers respond quickly to pull requests when they are opened?
    3. Is there active discussion on the pull requests?
    4. Are the pull requests recent?
    5. How recently were any pull requests merged? (On GitHub, click the “closed” tab on the Pull Requests page to see closed PRs.)

Please review in complete the, which explains how to contribute on Github and other open source enabling platforms.

5. Standard operating procedures for the project

The Auravana Project is an open source and free shared research project.


  1. This section represents the standard operating procedures (SOPs) for the project.
  2. This standard operating procedure (SOP) section will undergo modification to accommodate changing conditions in the environment. This SOP acts as the procedural system defining how the project will operate in public.


  1. Through research and design this project exists to develop a set of standards, and complementary content, for the construction and operation of a community-type society. All tasks and procedures shall orient our decisions and actions toward this goal.


  1. The Auravana Project has no active social media accounts.
  2. The Auravana Project primary coordinator’s Twitter account is located on the homepage and is used to share project updates.
  3. As a member, be careful of making claims about the project without a directly published reference to substantiate the claim. 
  4. As a member, all commenting on all social media sites is to be done through your own social media account. Hence, there is no approval system for commenting (i.e., subjective posting), because this is to always be done through an individual’s personal account. It is expected that when someone comments through their personal account that they are to be respectful at all times.


  1. The primary email account for the project is for formal and professional interaction, and for the development of constructive relationships that are likely to lead to tangible contribution to the construction of the system.
  2. The project coordinator receives and responds to general inquiries to the project.
  3. All interactions shall be simple, precise, formal, and objective, and without any commenting or subjective influence. If a subjective or comment-like response is desired, then a personal email account shall be used. 
  4. All emails will be made available (per prompt or request) to all tangibly active contributors to the project.


  1. The contact form sends a message to the orientation channel of the Auravana Projects working group communications platform (currently, Slack).
  2. Eventually, contributors to the project may need to pay for Slack (if slack is still charging for required features); each member will pay an amount into escrow and the project coordinator will use the money in escrow to pay the fee. This may happen sooner than expected as the project grows rapidly. Unless, there are equivalently functional free alternatives.
  3. The coordinator sorts contact messages, and when appropriate, invites people to the the channel #contributor-orienteering.
  4. Channel coordinators sort tasks and invite people to their channels. Each channel is a working sub-group and represents a single article in one of the standards.
  5. Groups use their assigned channels to communicate. Do not communicate directly into groups that you are not a part of. Instead, use the channel #unified-standards-discussion.
  6. Error corrections received by the contact form will be sent on to those relevant contributors by project coordinators who must monitor the channel #contributor-orienteering for their issuance.
  7. Project coordinators will use channel #project-coordinators to communicate.


  1. The release of content produced by the project via a contributor’s social media accounts is not considered marketing (though it is understood that such content represents how the project is perceived by the public).
  2. Marketing shall be professional at all times, and shall always involve a notation that we are working on a set of standards that shall be used for the construction and operation of the system, so that this is seen as a possible and favorable direction
  3. Marketing shall be oriented toward the establishment of relationships that will facilitate, or are reasonably likely to facilitate:
    1. Tangible contribution.
    2. Relationships with the potential of facilitating the development and construction of the system.
  4. Marketing shall not assume any responsibility or obligation for the timeliness, missed delivery, deletion and/or any failure to store content.
  5. Marketing shall not lay claim to ownership of any content submitted by any contributor or user.


  1. As a sign of good faith, if someone files a copyright claim, then the content will be removed as soon as possible. This is similar to YouTube’s procedure, which involves initial removal of the content and then a procedural system for resolving the issue.
  2. After the content has been removed an email shall be sent to the initiator of the conflict requesting verification of the infringement and reasoning for the takedown. Primary email account usage procedures should be followed during the course of this interaction.
  3. An honest and authentic organization would contact us first through an open dialogue, and ask us to remove the offending contact, while facilitating an appropriate resolution.