Join the discussion on the Fediverse with #FediLibrary.

Contributing

Adding a new work to the library is intended to be easy. All that is required is a Fediverse account, and a willingness to grant this site with a Creative Commons License Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License, or similar. By following the submission process, you are agreeing to granting a license to the work.

This digital library is, much like a real one, intended to be informative and useful. There is a baseline expectation of sincerity and quality, but it should not be a concern to anyone earnest in their efforts. Spammers, trolls, and those trying to purposefully toe the line to prove a point may find their submissions rejected. Submissions by a person of another person's work will be rejected, even if done in good faith to boost a friends' voice. All works must be in a long-form or essay style. Short toots or quips will be rejected.

We only accept written content for a problem, an analysis, an experiment, or an objection, though the definitions are quite flexible. Supporting images are typically omitted, but if they must be included, it will be reviewed on a case-by-case basis.

Are you interested in contributing an existing or new piece of work? It could be written on your blog, in a note on a code repository, or just directly submitted through the below process. In all cases, the textual content will be reproduced on this site in its entirety. For existing works on other websites, including personal sites, a source link will be prominently included so readers can find the primary source.

Short-Names

All accepted submissions are given a short acronym. This acts as an easy way for others to easily refer to your submission in the future, and allows you to refer to previous submissions with ease. We use short-names to make sure the community has a quick way to refer to our content when discussing in the wild, and use it in the submission process.

Their name like WEB-1 typically reflects the origin and order of the submission.

How do I make a submission?

This submission process is manual given the expectation of how few and infrequent submissions are expected to be. It is temporary given that there may be others that wish to help out in running the digital library.

By following the submission process, you are agreeing to granting a license to the textual work under: Creative Commons License Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License, or a similar license of your choice.

The mandatory steps are:

  1. Send one or more direct message(s) to @cj@mastodon.technology with the submission simply typed into the DM directly (if new content), or a link to your blog (if existing content).
  2. Include a title!
  3. You must indicate if the submission is an objection, and otherwise may indicate whether this is a problem, an analysis, or an experiment. It can only be categorized as one thing. It's OK to omit your categorization and skip this step entirely if it is not an objection.
  4. In the special case of submitting an objection, please provide one or more short-names that the objection is objecting to.

Optional things to include:

  • If the submission is an analysis, you may indicate which problem(s) the submission is analyzing. In addition to any suggestions you make, we may indicate additional relevant problems.
  • If the submission is an experiment, you may indicate which analysis/analyses the submission is providing an experiment for. In addition to any suggestions you make, we may add additional analyses that appear to fit.
  • In the special case of submitting an experiment, please be sure to provide a link to a code repository, if one exists.
  • Finally, you may include any short-names you feel are related to your piece's topic. In addition to your suggestions, we may add additional short-names that relate to the topic.

From there, the submission will be processed as follows:

  1. A response letting you know the submission was successfully received.
  2. The submission will be reviewed; if more information is needed then a DM back and forth will happen.
  3. If there's been heated discussion that has generated submissions that reflects a charged atmosphere, numerous submissions, and/or numerous objections, we may reach out to confirm whether to proceed with the submission process for all submissions sent in this period of time.
  4. If everything is in order to begin with, or once everything is in order, you'll be informed whether the submission was accepted/rejected.
  5. If accepted, the submission will be given a short-name and added to the website.

We handle adding tags to accepted submissions. If you strongly disagree, please reach out after the fact.

The expectations for different categories of submissions are below, but they are more of guidelines and are not rules. Don't get discouraged by them!

What are the expectations for submitting a "problem"?

A work in the problem category typically outlines something challenging with Fediverse software or the ActivityPub protocol. It can be something as specific as a traditional "problem" or as broad a general area to draw attention to. These submissions should strive to capture and define an area of improvement as much as possible. It helps to try to have one submission stick to one problem. In contrast, an analysis is better suited for tying problems together.

Characterics of a good "problem" category submission involve supporting evidence (such as links or case-studies), focusing on one topic (even if it is broad), and providing a good launching point where others can use the problem outline to develop analyses. It answers the question: "what is a challenging open problem area?"

We're more likely to label something as an analysis if an article starts digging deep into the problem(s) with ideas for potential solutions. It means things are less likely to be labelled in the "problem" category since people tend to like to seek solutions, but those that are in this category really do exercise restraint in the solution space and focus heavily on documenting problematic technical or non-technical behaviors.

What are the expectations for submitting an "analysis"?

A work with the analysis category is the heavy lifting that ties together one or more problems in order to identify areas that may have technical or non-technical solutions. These submissions capture a particular approach to addressing a community-identified problem. Different analyses may address the same problems in different ways, with differing viewpoints. It is expected that analyses need to build off of each other, and take into consideration objections, to really reach a high-quality and well-documented community understanding.

The characteristics of a good analysis include addressing one or more problems coherently, providing an argument for the way it tackles certain problems, and supplying reasons for or against approaches. The approaches could be technical, but do not have to be.

We're more likely to put submissions in this category than any other category. Giving opinions, providing status updates on specific software, contributing to ongoing discussions around solutions, and thinking about how to positively affect the community often falls into this very broad definition of an "analysis".

What are the expectations for submitting an "experiment"?

A work classified as an experiment is a technical software piece of work that explores an approach, perhaps outlined in an analysis. It may be accompianied with its own analysis explaining the motivation of the experiment and the way the experiment specifically functions. It would be especially helpful, but is optional, if it explained how it could or would be adoptable by ActivityPub or Fediverse software, whether it is backwards-compatible, and other such considerations.

Of course, experiments can be done without being tied to other pieces of work here. But the most impactful will be able to draw a line from the community-identified problems, through analyses, to here.

Characteristics of a good experiment include open source code and tying the technical work to the community need.

We're likely to put specific technical explanations, technical tutorials, and non-technical specific community-building attempts into this category.

What are the expectations for submitting an "objection"?

An objection submission is best used when you have concerns with any other kind of work -- even another "objection"!

These are the highest risk at capturing intense, heated conversations. The intention is to have the community treat objections as though they are serious concerns and treat the people putting them forward as helping forge and refine good ideas, and helping push back against the bad ones. Just because someone submits objections does not make them a bad person.

Objections provide an opportunity to identify concerns and track whether they have been adequately addressed or remain unaddressed. The community may identify ways to address it in whole or in part, or mitigate its concerns in a way some find acceptable. For example, let's say an analysis had some objections, but now the author of the analysis has talked to the objecting parties and found some new common ground. As a result, the submitter is welcome to submit a new analysis or individually submit objections-to-the-objections. The submitter is the best at determining which to persue.

Since objections are at-risk at leading to non-constructive conversations, this site encourages you to submit works that are the most productive and effective as can be. We appreciate your consideration and not putting the submission reviewers in an awkward position.

A characteristic of a good objection is concretely identifying specific concerns in the material being objected to. It answers the question "what is concerning?", such as technical details or patterns of behaviors within the community.