Working in a team with and for Hyperbola

The basic rules for Hyperbola as a project are defined by our Social Contract document. The purpose of this Teamwork document is to define what it means to work with and for the Hyperbola community as a contributor. Generally, Hyperbola looks for the following in its contributors:

  • a willingness to help and support the project
  • the ability to work independently
  • good communication skills
  • an orientation towards the UNIX design philosophies of minimalism and technical emancipation

The following points are intended to define both acceptable and unacceptable behaviors from contributors. These are based on general guidance for projects such as Hyperbola, as well as to address specific situations that have arisen throughout the history of the Hyperbola project. We would like to underline that those rules here are surely in further development, so if anyone feels uncomfortable with one or more rules please speak up open with us. But also note that we then would like to work on a counterproposal. Criticism without any proposal for alternative is not working.

  1. Respectful for each other: Every team-member can await to be treated fair, but also has the commitment to respect other members same way. When there is something to debate, we demand that people get in touch with each other and clear up issues and problems and don't search only to create scandals. This kind of dramatic staging is not tolerated here at Hyperbola and also not within the team as this is not respectful treatment. Please also never use sealioning and bikeshedding in your approach for argumentation. Direct, but friendly approaches, including respect and inclusion is the way Hyperbola is using. Not the opposite as bikeshedding for example means focusing on the minor details in a discussion rather than the issue at hand. We have no interest in useless debates and accusations.
  2. Stating open about difficulties: Not everyone has the same knowledge about everything. So every team-member should talk direct and open when something is not clear. Problems are made transparent, but also with clear and straight facts and not with interpretations.
  3. Not awaiting any advantages: Team-members should not await a better position. So being part of the team working on Hyperbola means also to work with and for Hyperbola. Being part of the team just to present this like a trophy elsewhere is nothing we want here.
  4. Activity and help: Hyperbola is oriented on its community and therefore team-members should do the same. Nevertheless there is nothing enforced. When a member has no time or lost interest, it is just helpful leaving a note about tasks not fully solved or left open for the moment. It is also fair to give this back instead to remember people endless and therefore combines with respect. The best way is surely to leave a mail so people have something to remember and work for. After 3 months of inactivity a team-member is also marked as inactive (Members Fellows). There is in general no issue to ask for return any time, but we think it is clear to understand that inactivity is the wrong sign especially when people look on how to support Hyperbola, see a number of in their perspective sufficient helping persons and stop while exactly the majority marked as “active” are no longer working on, for and with Hyperbola. But also to note: Dramatic staging does not bring back anything and makes it even more complicated to return. Please understand that “respect” is not only a word here: If you think to treat people whatever you like and use them for your own projection space they won't be amused and willing to work again with you.
  5. Using Hyperbola to build Hyperbola: Yes, no one is forced to use Hyperbola, but as team-member it does not make any sense when someone is using a complete different system. So either as own installation or on a daily base we encourage and await the usage of Hyperbola for developing also within it as system.
  6. Misbehaving: As already noted in the first point we ask for respecting each other. So what is the point when this is not done? We will refer to our social contract in that case. But also to clear up: We do not tolerate misbehaving, harassing or anything in that direction. Every community-member is invited to participate. But to use Hyperbola only for own advantages, to make accusations towards team-members or other kind of actions is nothing we support. This also may lead to the point that there is no further return as team-member.
  7. Misusing Hyperbola: Hyperbola offers many possibilities and surely also independence and technical emancipation as common major orientation. But every team-member should follow same ethical and moral principles, including also not to misuse Hyperbola and the community only for own advantages, for example to misuse donations. So far approved and getting into knowledge this will lead to the immediate discharge as part of the team, no option for returning. Hyperbola is also not a mirror for “activism” and is not meant like this. Free, libre software is done with altruistic motivations in our perspective, so this means engagement for each other without endless questioning and also being active engaged. Some phrases being used to describe Hyperbola may help, but in general bring nothing more when there is no activity behind them and persons stating only use those to mark something as bad or blame others. Especially this is something we also decline in our team.
  8. No hearsay, lies and half-truths: Every community-member and member of the team has the obligation to approve information and correct them when discovered not being true. Nobody is perfect, but we have no time for those and do not want to offer room for hearsay and conspiracy theories. Free, libre software is not political neutral, but also not a constant tool for support more paranoia. Spreading this in the context of Hyperbola is not acceptable in any way, neither for members of the team nor the community. We do not want to be part of anyone's special conspiracy theories, we also do not want to have Hyperbola being part as tool to attack democratic principles. So we oppose this active for sure and await this also from every member in our team and community.
  9. Working and talking together: We have every week a meeting in IRC, where we give insights for transparency. Besides we await for sure that every team-member is getting in touch together and work independently on matters together. We do not tolerate to claim being independent and misuse Hyperbola for own purpose driving the project into a complete different direction.
  10. Not your own dreamcastle: Yes, Hyperbola is about acting with and for free, libre culture and software. But also no as Hyperbola is not about the fulfillment of any personal “dreamcastle”-buildout. If people want to start something with and / or on top of Hyperbola, they can always feel welcome. But this is inbound with doing, not only with some statements and empty promises. If you want to do, please do and approve your doing. Not just think that you can be part of a team and others carry out and realize your wishes.

If you do not see some points here fitting for you or you want to make your own rules, we kind but straight ask you to stop asking for being a member of the team (and the community also) as this does not make any sense: Hyperbola is not meant as your personal playfield for your visions, when you only want to talk, discuss and let others do work and realize your “ideas”. The system is meant to enable you working with your hardware, but reasonable and not meant on behalf of irretational thoughts. Decisions, workfows and more were made out of reasoning. They are surely part of discussion in time and can be optimized together. But the keywords here are working together, teamwork and decision making together. This implies also to accept existing workflows. If you have proposals to change them? Sure thing, but demanding from everyone to follow only your perspective without any approval is not working for this project.

How to become part of the team?

Surely interest in Hyperbola is one thing, but another also the commitment to support and develop on the base of Hyperbola. At minimum a constant timeline of 3 months supporting and helping out. Perhaps guidelines in the forums? Or sharing patches and improving existing packages also sharing new ones? Also willing to respect all the points noted above for sure.

And how to leave the team?

Preferred way would be to note the team-members that there is the will for leaving: No interest, no more time for the moment or other issues - no need to go into details. But also being inactive for more than 3 months is a sign given. As said there is in general always a possible return. The exceptions given also noted above: Being dishonest, misbehaving or / and even misusing Hyperbola for own advantages.