💾 Archived View for geminiprotocol.net › docs › faq-section-5.gmi captured on 2024-03-21 at 15:03:26. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-09-28)
-=-=-=-=-=-=-
Easily the most important contribution you can make to the success of Gemini is to add some content to Geminispace! The more interesting and exciting stuff people find in Geminispace, the more likely they are to want to keep using Gemini and eventually add content of their own. See question 2.5 above for details on how to get your content into Geminispace. A lot of people wish there was less computer related content in Geminispace. If you feel like you can add some more variety to the space, go for it!
If producing original written content isn't your thing but you'd still like to help populate Geminispace, you could find some Creative Commons or similarly permissively licensed content to rehost. Don't republish a bunch of stuff just because it's CC, though. Try to find something which you actually think is interesting or entertaining or otherwise worthwhile, and try to pick something which adapts well to Gemini's technical limitations. The Wikipedia list of major CC works may provide a helpful starting point for ideas:
Wikipedia's List of major Creative Commons licensed works
If you have the necessary technical skills, you can make a major contribution to the growth of Geminispace by providing a hosting service which people can use to publish content. This can be as simple as setting up sftp-only user accounts on a VPS. Offering hosting doesn't necessarily need to be a big commitment. You can use the cheapest VPS services on offer to very comfortably host a dozen or so users. A large number of hosts each serving the content of a relatively small number of users is a much more robust and sustainable ecosystem than a small number of servers each hosting hundreds or thousands of users!
More specifically, you could set up a hosting service which explicitly aims to fill a particular niche, by hosting content on a particular subject, or content in a particular language, or content written by a particular group of people. With a catchy name and an integrated aggregator for hosted content, such a service could easily become a valuable community hub.
More hosting options for people without system administration skills would certainly be welcome. This might take form of more services like those listed in section 2.5.1 with easy interfaces. Or it might take the form of more traditional hosting technologies like (S)FTP or git but with high quality documentation aimed at helping people to learn these tools, coupled with a volunteer help community.
You don't necessarily need to provide something like a traditional hosting service where each user builds their own capsule from scratch. You could set up a capsule designed to host a particular kind of content, say reviews of video games, or films, or albums, or maybe recipes, or home improvement advice, or fun games you can play with a standard deck of cards, or whatever. In addition to possibly writing some of that content yourself, you tell Geminispace at large that people can email you submissions. If you get submissions and you think they're good, you upload them to the capsule, attributing the original author however they'd like to. You can impose your own standards, be they high or low, for originality and quality of the content. This still functions like hosting. It helps fill Geminispace with content, and requires no technical skills on behalf of contributors other than being able to send an email.
Geminispace is constantly growing. It's decentralised, which is a good thing, but because of that it's disorganised, which isn't necessarily. There are search engines (see 2.2.3) and aggregators (see 2.2.1), but there is still plenty of room for improvement and innovation in making it easier for people to find content of interest.
In the earlier days of Geminispace there were some categorised directories (see 2.2.2). Usually these were projects run by a single person or small group, and attempted to organise the entirety of Geminispace. Unsurprisingly, that's very hard to keep up long term, and a lot of these directories have gone offline or stopped being updated.
There hasn't been much yet in the way of attempts by larger groups to maintain directories of specific subsets of Geminispace. This approach would result in a substantially lighter workload and might allow more fine-grained categorisation. Directories could include content at the level of individual pages, rather than entire capsules (which are very rarely exclusively dedicated to a single topic, anyway). If such directories provided subscribable pages or Atom feeds of newly added content, the content submitted to separate directories on distinct but somewhat similar or related topics could be aggregated into larger directories organised by higher level thematic concepts. Starting up some projects along these lines could be a worthwhile experiment.
Gemini already has a surprising number of client and server implementations in existence. That's not to say more aren't welcome, and if this is something you'd really like to do, you should feel absolutely free! But if you really want to make a contribution that will help the project to grow and thrive, and you'd like to do it by writing code, writing tools, applications and platforms might be a better bet.
A powerful tool for expanding Geminispace could be a single piece of software which simultaneously provides a Gemini server and a way for multiple users to easily manage the content provided by said server, e.g. via an interactive web interface or by sending emails full of content; Something like the Gemlog Blue and Flounder services (see question 2.5.1 again), but packaged up and documented in such a way that it's easy for people to deploy and customise their own multiuser sites, much like e.g. a Mastodon instance.
All the documentation hosted at geminiprotocol.net, including the FAQ you're reading now, lives in a single git repository, which has read-only access open to the public. You can clone the repo as follows:
git clone git://geminiprotocol.net/gemini-site
Then, make your suggested changes to the relevant files (the structure of the URLs mirrors the structure of the repository exactly, so e.g. gemini://geminiprotocol.net/docs/faq.gmi lives at docs/faq.gmi in the repo). Commit your changes with meaningful commit messages (make sure to set your name and email address so people can see who did your work!), with one commit per conceptual change. You then have two options to send your work upstream.
If you have git's send-email command configured (see below for a link to a tutorial), you can email patches containing your commits to <solderpunk _at_ posteo _dot_ net> with a single command. Otherwise, you can simply run:
git format-patch origin
to create a set of patch files, which you can manually attach to an email using your ordinary mail client of choice.
A friendly tutorial on configuring git send-email
Please note that if you update the FAQ, it is sufficient to update only the faq.gmi file. The separate files for the individual FAQ sections can be automatically updated by Solderpunk using a script when your patch is merged.
Thank you! Volunteering to translate documentation is a wonderful way to help the project.
To do so, first clone the git repository as described in question 4.2 above. Change into the `doc` directory of the repository, and create a new subdirectory with your language's two letter ISO 639-1 code, e.g. Finnish translations should live in `doc/fi/`, Japanese translations in `doc/ja/`, etc. You can find a complete list of codes at Wikipedia, linked below. If you are translating into a region-specific variant of a language, you can use RFC4646-style codes instead, e.g. pt-PT or pt-BR for the Portuguese as spoken in Portugal or Brazil, respectively.
List of language codes at Wikipedia
For each English file which lives in `doc` which you want to translate, create a corresponding file in your language's subdirectory. It's okay to change the file name as part of the translation, e.g. the German translation of `doc/specification.gmi` might be called `doc/spezifikation.gmi`. You can translate as many or as few of the files in `doc` as you have time and energy for. Don't be shy about submitting partial translations! Once somebody else who speaks your language sees your effort, they might provide some or all of the remaining work. Having some content translated is better than none.
Once you're done, copy across the `doc/index.gmi` file and modify it to match your translated filenames and document titles, and remove links for any of the original documents which you haven't translated yet.
Finally, update `doc/translations.gmi` to include a link to your new subdirectory.
Commit your translations to the repository and send Solderpunk the patch as described in question 4.2 above.
Next section: Gemini-adjacent technologies and cultures