project-trans/MtF-wiki: a community maintained knowledge site for transgender women

What the site is for

MtF.wiki is described as a free, open and continuously updating transgender female knowledge integration site, and the Chinese README puts the scope more precisely. It is a place that may help some transgender women and gender diverse people, and it aims to be a knowledge integration site for female leaning transgender topics where people can find medical information and various guides related to being transgender.

The term the site uses for its subject is defined in the README. MtF, Male-to-Female, refers to women whose assigned sex at birth was male.

Two things stand out about how the project frames itself. The first is that it is explicitly a knowledge integration effort rather than a single article, which is a distinction that matters for a subject where the practical question is usually a mix of medical, legal and social, and where the same source may be needed by several people at once.

The second is the mission statement, which goes beyond documentation. Beyond providing a knowledge platform for the community, the project says it hopes to see affirmation of the decision to transition, and it states a commitment to equal choice in sexual orientation, gender identity and gender expression, free from stigma, discrimination and violence, on the grounds that this helps build values of equality and respect and creates a more friendly society.

That is why the project also runs a sister site, FtM.wiki, for the transmasculine side of the same subject, and why the two are linked from the top of the page.

A project that says it is early and asks for help

The paragraph on the current state is the most useful sentence in the README for anyone deciding how much weight to put on the site. The wiki is at a starting stage, the various materials may not be complete and may even contain some errors, and the community is warmly invited to join in and contribute to its development.

That candour is unusual and it is also a design decision, because it reframes what a wiki is for. A knowledge site that presented itself as finished would generate less correction, and a knowledge site that generated less correction would be less accurate over time. The stated model is the collaborative one: readers who find an error are the ones best placed to fix it.

The repository carries that commitment in its structure. There are badges for contributors, for the last commit and for the commit activity by year, which are the sort of counters that make a slow, distributed, volunteer project legible to a newcomer. The README also has an acknowledgements section, crediting the many sources consulted while writing the project, which is a small thing that means a lot in a subject where readers need to know where a claim came from.

The project is published under four readme languages in the repository root, the Chinese original with Traditional Chinese, Japanese and English versions as `README-T.md`, `README-JA.md` and `README-EN.md`, and the site itself carries a language switcher. The English readme is the shortest of them, which is worth remembering when you read a translation.

CC BY-SA for the text, with the code excepted

The licence is the part of the repository that most affects how a reader can use the material.

Except where otherwise noted, everything in the project apart from the code is licensed under the Creative Commons BY-SA 4.0 International licence. The README paraphrases the terms: you are free to share and to adapt, but you must give attribution, share under the same licence, and distribute without additional restrictions.

For a knowledge project, that is exactly the right choice, and it is worth being explicit about what it enables. Because the content is share alike rather than copyleft on software, a translator, a clinic, a local community group or a documentation project can take a page, adapt it for their own audience and publish it, as long as the attribution and the same licence travel with it. There is no permission to be sought from a central owner, and no point at which the material becomes private.

The repository also provides a citation artefact, in the form of a BibTeX entry you can use to reference the repository in an academic context:

@misc{mtfwiki,
  author = {Project Trans},
  title = {MtF.wiki},
  year = {2020},
  publisher = {GitHub},
  journal = {GitHub Repository},
  howpublished = {\url{https://github.com/project-trans/MtF-wiki}},
}

and a `CITATION.cff` file in the tree, which is the format GitHub reads to show a Cite this repository button. Two citation formats for the same thing is mild redundancy, and it is the kind that makes citing a wiki rather awkward to do properly, so having both is sensible.

One caveat to keep in mind when you read the terms. The README scopes the CC licence to everything except the code, and the code portion is therefore licensed separately, so if you want to reuse a script from the repository rather than a page of text, that is a different question from the one the README answers.

A static site with the content in one directory

The repository is small and legible, which is a good sign for a project that is mostly text.

There is a `content/` directory holding the site content, a `static/` directory for the assets, and a `content.code-workspace` file that opens the content tree in an editor with the right settings. The `CNAME` file at the root is the GitHub Pages custom domain, which is how a repository becomes a site without a build pipeline in the usual sense.

The tooling around it is the usual set for a documentation and content project. There is a `.markdownlint.json`, so the Markdown is linted, an `.editorconfig` for whitespace and encoding, a `.ecrc` for a spell checker, and a `.imgbotconfig` for an image optimisation bot that keeps the image files in the repository small. There is a `.vscode/` directory for editor configuration and a `.github/` directory for the workflows and templates.

Two of those deserve a note. The markdownlint configuration means the formatting of the text is checked, which keeps a large wiki from drifting into inconsistent heading levels and spacing as dozens of people edit it. And the image bot configuration is the kind of detail that only matters at scale, where an image heavy wiki with hundreds of screenshots starts costing real bandwidth.

The site is versioned in the ordinary way, with the master branch as the default, and the last push to the repository was on 2026-10-14 with no release tags, which is what you would expect from a repository whose unit of change is a page rather than a version of software.

Where this is the wrong reference

The first wrong case is treating the wiki as a clinical source. The project describes its own material as being at a starting stage, possibly incomplete and possibly containing errors, and the subject matter is medical. A page about hormones or surgery is a starting point for a conversation with a clinician, and the responsible way to use the site is as orientation rather than as a protocol.

The second wrong case is assuming a page is current. A wiki that is continuously updated is also continuously changing, and a reader who found a page accurate a year ago cannot assume it is accurate now, particularly on a subject where guidance changes as evidence and practice change. The page's own date and its sources are the things to check, not the site as a whole.

The third wrong case is expecting coverage of everything. The README says the materials may not be complete, and a subject as broad as this one has many subtopics, from medical pathways through legal processes to social situations, and a wiki at an early stage will be uneven across them.

The fourth is a technical one. If you want to build a searchable knowledge product on top of the content, the share alike licence obliges you to keep the adapted content under the same licence, and the structure of a wiki repository, a directory of Markdown with a static site in front of it, is a starting point rather than an API.

None of that is a criticism of the project. A volunteer knowledge base that is openly licensed, openly corrected and openly incomplete is a more useful contribution to a community than a polished document that nobody can change, and the project has made the trade deliberately and says so in its own words.

Editorial conclusion

Adopt MtF.wiki as a reference for your own work if you are building something for transgender women, because a constantly updated community knowledge base with a permissive share alike licence is easy to reuse and to correct, and its README asks for corrections rather than treating the text as final. Do not treat it as a clinical authority, because the project itself says the material is at an early stage and may be incomplete or partly wrong, and any medical decision needs a clinician rather than a wiki page. Verify first which language version of a page you are reading, since the site is translated and the repository keeps separate readme files per language, that the page you cite has a date and a source, and that the licence terms you are working under are the CC BY-SA 4.0 that the content uses while the code in the repository is separately licensed.

Frequently asked questions

Official sources

1. Issues
2. License: CC-BY-SA-4.0
3. project-trans/MtF-wiki on GitHub
4. Project website
5. README