• Rules of Frolic’s Development
  • Purpose
    • The project exists for the people who use it.
  • Development Style
    • Everyone is allowed to help.
  • The Golden Rule

---

Rules of Frolic’s Development

Purpose

The project exists for the people who use it.

1. All things that improve the experience of the end user should be considered.
2. The developers are also users, so they should not discount themselves.
3. The purpose of the app is to assist. Taking action is reserved for the user.

   Yes: Suggesting topics for starters based on profile information; pointing out commonality between users; highlighting messages the user may want to see

   No: Silently blocking messages or users; botting (sending messages, etc) on behalf of the user

4. Along the same line of thinking: Leave the decision-making to the user. To have the app cast harsh judgment is forbidden.

   Yes: Tagging search results with colors based on preferences; Dimming users who you are unlikely to want to pair with; sorting search results by some criteria

   No: Hiding characters from search results entirely;

5. Aspects that improve the user’s life should be amplified and focused upon. The user should feel uplifted for using the work (in comparison to its alternatives).
6. Aspects of the work that insult or demean people should be diminished or compensated for.

   Yes: highlighting desired criteria of characters; pointing out misalignments with other characters in neutral, informative ways

   No: Big, scary “No” tags on users based on general, immalleable criteria. “No” tags have long been a point of contention of other F-Chat clients, since they frequently result in no contact initiated, and thus prevent real, human judgment from ever taking place.

Development Style

Everyone is allowed to help.

All steps of collaboration require human-to-human interaction.

1. Understand that giving critique to others and having others critique you is the exact same situation.
2. Good communication includes being truthful and direct, but exercising precision when offering critique.
3. Every interaction is an opportunity to develop your communication skills.

Requirements must be kept shallow to allow for the most potential contributions.

1. Possibly, we will be flooded with low-quality submissions - a necessarily evil.
2. If improvement is needed, opportunity should first be given to the contributor to make the improvement.
3. Some good ideas may go unimplemented for eternity, but it’s the reality of understaffed projects.

Issue reports are welcome from everyone, though not every issue is addressable.

A realistic code submission process can allow any member to help, without burdening them with a complete task.

1. Collaboration should be leveraged to make life easier for everyone - people can contribute where they are comfortable and leave the rest up to others.
2. Code should be readable, but a specific style should not be enforced.
3. Code must be submitted under a freedom-granting license so other collaborators can tidy, fix, finish, or rework the code as needed.
4. Squash your typo fixes. Please.

These rules are ever-evolving to provide greater help to the real people who read them.

The Golden Rule

1. Where rules and reality conflict, reality must reign. Bad actors cannot be tolerated just because they abide by the letter of the law while violating the spirit.

---