pleroma/pleroma-meta
1
0
Fork 0
Code Issues 55 Pull requests 2 Projects Releases Packages Wiki Activity

The Goals and Non-goals of Pleroma #121

Open
seanking wants to merge 2 commits from gitlab-mr-iid-3 into master
pull from: gitlab-mr-iid-3
merge into: pleroma:master
Conversation 9 Commits 2 Files changed 1 +19
seanking commented 2022-04-08 04:58:58 +00:00
Member
Copy link

This MR simply adds a markdown file called GOALS.md, which outlines both the goals and non-goals of Pleroma.

This MR simply adds a markdown file called `GOALS.md`, which outlines both the goals and non-goals of Pleroma.
ilja commented 2022-05-08 09:13:31 +00:00
Member
Copy link
* **Simple to set up and manage** - We want setting up, managing, and getting our software up and running to be as easy as possible for anyone.
* **Flexibility** - Although Pleroma's main purpose is for microblogging, we want our software to be flexible enough to use for other purposes.
* **Easy to get into development** - We want to make it easy to get into developing for Pleroma, especially since our software is free and open-source.
* **Scalability** - We want our software to be easy for anyone to host. Additionally, we want our software to scale easily for various use cases, ranging from small computers hosting a few users to small and medium servers hosting large instances.

Not sure if order really matter much, but if it does, this is how it's for me. (Anyone, feel free to argue against obviously.)

  1. "Simple to set up and manage" because this is our direct user base and has the biggest impact (if it's pain to set up or run, people wont run it).
  2. "Flexibility" comes later because what's it worth if we don't have people willing to run it anyhow ʅ（´◔౪◔）ʃ
  3. "Easy to get into development" is related to flexibility, but a step deeper. Not everyone will want to develop. It's important, but with less impact than the first two, so I consider this third.
  4. "Scalability" is definitely less important than "Simple to set up and manage". And I think the impact is smaller than "Flexibility". I put it last because I feel there hasn't been much focus on it in the past. But maybe I'm wrong and this one should go higher, idk.
```suggestion:-3+0 * **Simple to set up and manage** - We want setting up, managing, and getting our software up and running to be as easy as possible for anyone. * **Flexibility** - Although Pleroma's main purpose is for microblogging, we want our software to be flexible enough to use for other purposes. * **Easy to get into development** - We want to make it easy to get into developing for Pleroma, especially since our software is free and open-source. * **Scalability** - We want our software to be easy for anyone to host. Additionally, we want our software to scale easily for various use cases, ranging from small computers hosting a few users to small and medium servers hosting large instances. ``` Not sure if order really matter much, but if it does, this is how it's for me. (Anyone, feel free to argue against obviously.) 1. "Simple to set up and manage" because this is our direct user base and has the biggest impact (if it's pain to set up or run, people wont run it). 2. "Flexibility" comes later because what's it worth if we don't have people willing to run it anyhow ʅ（´◔౪◔）ʃ 3. "Easy to get into development" is related to flexibility, but a step deeper. Not everyone will want to develop. It's important, but with less impact than the first two, so I consider this third. 4. "Scalability" is definitely less important than "Simple to set up and manage". And I think the impact is smaller than "Flexibility". I put it last because I feel there hasn't been much focus on it in the past. But maybe I'm wrong and this one should go higher, idk.
ilja commented 2022-05-08 09:31:14 +00:00
Member
Copy link

I think I saw the idea of also including non-goals. An example of a fedi project which does this is Epicyon, see https://gitlab.com/bashrc2/epicyon/-/blob/main/README_goals.md. Our non-goals are different than Epicyon's, but could provide some inspiration.

Personally I consider the following non-goals for Pleroma:

  • Harassment - We want to provide a positive experience on the fediverse. Features who mostly encourage harassment shouldn't be supported. This includes things that can be easily abused like block-notifications, shared blocklists, and federated moderation.
  • Enterprise features for use cases applicable only to businesses - Pleroma can and may be used by businesses, but it's primarily designed for people and the community. Features for businesses should be done in a way that adds value for the community in general, or maintained in a separate fork.
  • promotion and integration of centralised and/or non-FLOSS software and services - We release Pleroma under a copyleft free license. Our users should be able to trust that we will not undermine their freedoms which we provide through our license.
    • This includes listing (and thus promoting) non-floss software and services unless it provides reasonable value to the community, and is not enabled by default. For example, listing non-floss apps to use with Pleroma doesn't provide much value because people who already use it, don't need it listed, and people who don't use it yet, shouldn't be pushed to non-floss apps. It's better to provide incentives to developers to create floss apps instead. OTOH, adding example settings for connecting the Mailer to a proprietary service can be considered providing reasonable value as long that there are other, more free, options provided. People aren't going to use this proprietary option just because we list it. It's rather the other way around, we list it because we know (how much it pains us) that many people are still dependent on it.

Edit: Note that these are just my personal takes, not necessarily that of Pleroma as a project. I don't think we talked about non-goals yet. This is more meant to start a conversation about them. The end result could very well be that we have very different non-goals, or even no non-goals altogether.

I think I saw the idea of also including non-goals. An example of a fedi project which does this is Epicyon, see <https://gitlab.com/bashrc2/epicyon/-/blob/main/README_goals.md>. Our non-goals are different than Epicyon's, but could provide some inspiration. Personally I consider the following non-goals for Pleroma: * **Harassment** - We want to provide a positive experience on the fediverse. Features who mostly encourage harassment shouldn't be supported. This includes things that can be easily abused like block-notifications, shared blocklists, and federated moderation. * **Enterprise features for use cases applicable only to businesses** - Pleroma can and may be used by businesses, but it's primarily designed for people and the community. Features for businesses should be done in a way that adds value for the community in general, or maintained in a separate fork. * **promotion and integration of centralised and/or non-FLOSS software and services** - We release Pleroma under a copyleft free license. Our users should be able to trust that we will not undermine their freedoms which we provide through our license. * This includes listing (and thus promoting) non-floss software and services unless it provides reasonable value to the community, and is not enabled by default. For example, listing non-floss apps to use with Pleroma doesn't provide much value because people who already use it, don't need it listed, and people who don't use it yet, shouldn't be pushed to non-floss apps. It's better to provide incentives to developers to create floss apps instead. OTOH, adding example settings for connecting the Mailer to a proprietary service can be considered providing reasonable value as long that there are other, more free, options provided. People aren't going to use this proprietary option just because we list it. It's rather the other way around, we list it because we know (how much it pains us) that many people are still dependent on it. **Edit:** Note that these are just my personal takes, not necessarily that of Pleroma as a project. I don't think we talked about non-goals yet. This is more meant to start a conversation about them. The end result could very well be that we have very different non-goals, or even no non-goals altogether.
lambadalambda commented 2022-05-16 12:39:58 +00:00
Owner
Copy link

The non-goals should be removed altogether, they are either very vague or not the goals of developers (which they are free to pursue), but don't have much to do with Pleroma itself.

The non-goals should be removed altogether, they are either very vague or not the goals of developers (which they are free to pursue), but don't have much to do with Pleroma itself.
ilja commented 2022-05-16 12:58:15 +00:00
Member
Copy link

Yeah, these were really more my own personal takes rather than what I think is true for Pleroma as a project. The idea was more to have a talk about having non-goals (which I believe could make sense) rather than to have these specifically in. I should've been a bit more clear. I'll unresolve the thread again and make the motives of that comment a bit more clear.

Yeah, these were really more my own personal takes rather than what I think is true for Pleroma as a project. The idea was more to have a talk about having non-goals (which I believe could make sense) rather than to have these specifically in. I should've been a bit more clear. I'll unresolve the thread again and make the motives of that comment a bit more clear.
hj commented 2022-05-16 12:59:51 +00:00
Owner
Copy link

i would like to see some non-goals at least, i.e. "Our primary focus is federation and interop with the rest of the network, deliberate non-federating features or features purposefully breaking interop with other servers (apart from new features interop != compatibility) are out of scope of this project"

i would like to see some non-goals at least, i.e. "Our primary focus is federation and interop with the rest of the network, deliberate non-federating features or features purposefully breaking interop with other servers (apart from new features interop != compatibility) are out of scope of this project"
a1batross commented 2022-05-18 22:51:28 +00:00
Member
Copy link

Not causing feature creep would be also nice.

Backend at this moment is filled with unneeded stuff, like:

  • 1st april jokes(ssh&gopher access)
  • dead scrobble
  • dead admin api
  • two http clients and both are nearly broken
  • OTP builds that are causing more problems than just being easy installable
  • unreliable static-fe
  • overengineered solutions like emoji packs management.
  • ... and more

Does Pleroma really needs all of this at the same time?

Not causing feature creep would be also nice. Backend at this moment is filled with unneeded stuff, like: * 1st april jokes(ssh&gopher access) * dead scrobble * dead admin api * two http clients and both are nearly broken * OTP builds that are causing more problems than just being easy installable * unreliable static-fe * overengineered solutions like emoji packs management. * ... and more Does Pleroma really needs all of this at the same time?
seanking commented 2022-05-19 01:51:26 +00:00
Author
Member
Copy link

To be fair, I think the goals in and of themselves are fairly generic and could be easily twisted way too easily into fitting other folks' agenda more than actually helping Pleroma. By having non-goals listed, I think we can prevent those kinds of situations from happening for the most part. And given nothing really is final, we can expand upon/revise this before or after merging it.

To be fair, I think the goals in and of themselves are fairly generic and could be easily twisted way too easily into fitting other folks' agenda more than actually helping Pleroma. By having non-goals listed, I think we can prevent those kinds of situations from happening for the most part. And given nothing really is final, we can expand upon/revise this before or after merging it.
hj commented 2022-05-19 10:36:07 +00:00
Owner
Copy link

admin api isn't unneeded but it is unmaintained I guess.

admin api isn't unneeded but it is unmaintained I guess.
lambadalambda commented 2022-05-19 12:33:22 +00:00
Owner
Copy link

I some of these non-goals can be rewritten as goals, especially something like 'harassment' (we can't prevent harassment, but we can implement features that encourage good behavior and a good experience).

I some of these `non-goals` can be rewritten as goals, especially something like 'harassment' (we can't prevent harassment, but we can implement features that encourage good behavior and a good experience).
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin gitlab-mr-iid-3:gitlab-mr-iid-3
git switch gitlab-mr-iid-3

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch master
git merge --no-ff gitlab-mr-iid-3
git switch gitlab-mr-iid-3
git rebase master
git switch master
git merge --ff-only gitlab-mr-iid-3
git switch gitlab-mr-iid-3
git rebase master
git switch master
git merge --no-ff gitlab-mr-iid-3
git switch master
git merge --squash gitlab-mr-iid-3
git switch master
git merge --ff-only gitlab-mr-iid-3
git switch master
git merge gitlab-mr-iid-3
git push origin master
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
BE
No labels
BE
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
5 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
pleroma/pleroma-meta!121
No description provided.