RILAB statements: an archive of job and grant applications that worked

A repository of documents, not a project with an API

The description on the project record is two words long, Successful Job Applications and Grants, and the README heading is Successful Applications. The first sentence states the premise: all the job and grant applications here are successful, hopefully providing a diverse perspective on what has worked in jobs and funding.

That is the entire concept. There is no code, no build system, and nothing to install. The repository listing is the giveaway: a .DS_Store, a LICENSE.md, the README, and three directories named fellowships, grants and job_applications. The primary language on the project record is listed as unknown, which is what a repository of PDFs reports.

So the value proposition is direct comparison. A research statement written for a job market, a teaching philosophy statement, a diversity statement, a cover letter, an interview presentation: these are documents that are almost impossible to write from scratch and much easier to write once you have seen two or three that worked. Reading them tells you the expected length, the register, the level of detail, how much a specific institution is named, how personal the story is allowed to be, and how the funding agency is addressed.

The phrase diverse perspective is doing a lot of work in that opening sentence, and the way the archive is organised shows what it means in practice. The job applications are divided into three groups: industry and nonprofit research, research university, and primarily undergraduate teaching university. That division matters because the documents in those three groups are aimed at very different committees, with different expectations about teaching, publishing and the balance between them.

It is a document corpus rather than a project, and evaluating it means asking whether the examples are close enough to your situation to be useful.

What the files actually contain

The README is specific about the contents of the job applications, and the list is worth reading as a checklist of what an academic application can contain.

Job applications now include cover letters, CVs, research, teaching, and diversity statements, and even some interview presentations.

That is six document types in one archive, and the last one is unusual. A diversity statement is a specific genre, particularly in the US academic market, and it is the document people most often get wrong because there is little public guidance on what a good one looks like. Having several examples is a genuine contribution.

The interview presentations are the rarest item in the list. A slide deck for a job talk is a different artefact from a written document, and a repository that contains a few is unusual.

The other three directories are more conventional. The grants directory holds successful grant applications, and the README points to ogrants.org as well for additional grants. The fellowships directory holds successful graduate and postdoc fellowships, and it links out to Yaniv Brandvain's collection of NSF GRFP applications.

Two external references are given for the job applications, the UCSF career guidance page with sample resumes and cover letters, and the EMBO fellows career service resources for job applications. Both are pointed at as guidance and examples, which tells you the author considers the repository's own contents to be one more example set rather than a complete course.

The pattern across all three directories is the same: successful submissions, in PDF, contributed by the people who wrote them. The subjects are not anonymised, and the naming convention the README asks contributors to use makes that explicit.

The bias is stated up front, and it shapes what you will find

The README is unusually candid about the shape of its own collection, and the sentence is easy to miss because it is short.

There is a bias towards plants and evolution, as that's folks I know and can badger into contributing.

The reason given is social rather than technical. These are the people the maintainer knows personally and can persuade to contribute their documents, and the field follows from the network. It is a different kind of bias from the one a reviewer might worry about, because it is not selection for what got funded, it is selection for who was willing to upload.

The practical effect is that a plant ecologist or an evolutionary biologist will find a much richer set of comparable examples than, say, a computational linguist or a structural biologist. And the comparison quality within the plants and evolution set is high, because the same people are in the same funding and hiring market and read each other's documents.

There is a second consequence that follows from the first. These are successful applications, so the archive is a selection on outcome. It cannot show you what a rejected application looked like, or how near a decision a weak one was. Reading a strong document tells you what the ceiling looks like, not what is typical or what is safe.

The maintainer also links out to other collections, and that is the correct response to a narrow archive: the UCSF page for general guidance and examples, EMBO for more job application examples, ogrants.org for more grants, and the GRFP collection for fellowship applications. Read as a whole, the README is a signpost to several sources rather than a claim that this repository alone is sufficient.

Contributing means choosing a filename and accepting a licence

The How To Contribute section is short and the details in it are the ones that matter.

You can email the maintainer or submit a pull request if you would like to add to the repository. Files are to be sent as PDF, with as much information as you are comfortable including in the title, such as a name, a type, a year and an institution, or a name, a funding agency and a year:

`<last name>_<type>_<year>_<institution>.pdf`
`<last name>_<funding agency>_<year>.pdf`

The phrase as much information as you are comfortable including is doing deliberate work. You can submit a document with a redacted institution name, and the README does not require you to disclose which body you applied to. That is a reasonable accommodation, and it interacts with the licence term in a way worth thinking about.

The licence term is the significant line. Unless otherwise requested, your statement will be licensed under a CC by 4.0 license.

CC BY 4.0 is a permissive licence with an attribution requirement. It lets anyone copy, redistribute and adapt the document, including commercially, as long as they credit you. For a cover letter or a research statement, that is a strong grant of rights over a document about your own work, and it is the default unless you say otherwise.

So the contribution process is a decision point rather than a formality. If you upload, you are publishing a document under a licence that permits reuse, permanently and in a public repository, and the only way to keep it more restrictive is to say so explicitly at the time of submission. The email route and the pull request route both make that conversation possible; neither makes it happen for you.

The repository itself carries a LICENSE.md, and the project record lists the licence as a custom one that GitHub cannot classify, which is consistent with a repository that mixes its own terms with a Creative Commons licence applied to the contributed files. What the terms are is in that file rather than in the README.

Why successful applications cannot tell you much about failing ones

There is a limitation that is worth stating plainly, because it is the kind of thing that makes an archive more useful and less useful at the same time.

The archive is selected on success. Every document in it was attached to an application that worked. That gives you a reference for the tone, structure and ambition of a winning document, which is real information, and it is information you cannot easily get anywhere else.

What it does not give you is the distribution. A research statement that reads as excellent and a research statement that reads as adequate can both sit in the successful pile, and there is no way to tell from the archive which one the committee actually preferred. You can see the top of the range without seeing where the cut was, and without seeing the rejected documents you cannot calibrate your own.

There is also a publication effect that runs through the whole corpus. Someone who has been turned down three times and is proud of how they wrote the statement is exactly the person who is willing to upload it. Someone who was rejected once and has doubts about the process is not. So the archive is likely to skew towards the confident as well as towards the successful, and the confidence is itself partly a consequence of the success.

None of that is a reason to ignore the archive. It is a reason to read the documents as examples of what is achievable rather than as templates of what is expected, and to use the linked external collections, which include guidance as well as examples, to calibrate the difference.

Publishing your own application has a cost the archive does not mention

The README's contribution section is careful about what you may disclose, and it says nothing at all about what you gain.

A cover letter names a person, an institution, a role and a salary expectation, and often a supervisor or a research group. A research statement discusses unpublished work, ideas that are not yet public, and often names collaborators and specific projects. A diversity statement is the most personal document in the set. A grant application contains budgets, timelines, preliminary results and sometimes unpublished data.

Publishing any of these to a public repository is a disclosure decision, and the archive's contribution flow does not ask anyone to think about it explicitly. The default is that the file lands in a public GitHub repository under a permissive content licence, and the only mitigation the README offers is to omit the institution from the filename.

That mitigation helps with the filename and not with the file. A redacted filename is cosmetic if the document itself names the institution on the first line.

There is a professional dimension too. Many employers and funders have confidentiality expectations around applications, particularly at the point before an offer, and a successful application in a public archive is a document that was submitted to a specific committee under a specific arrangement. A contributor who uploaded in 2021 is not necessarily making the same disclosure a contributor would today.

For anyone reading the archive, the same fact applies in reverse. The documents are useful precisely because they are specific, and a reader should treat them as what they are, real submissions by identifiable people to real bodies, and not as generic templates to fill in.

What the repository is actually good for

Setting the caveats aside, there are three things this archive does that are hard to replicate.

The first is calibration of expectations. A research statement for a research university post and one for a primarily undergraduate teaching university position have different jobs, and the archive puts examples of both in the same place. Seeing a document that is short and teaching-heavy next to one that is long and publication-heavy is a faster way to understand the difference than reading guidance that describes it in the abstract.

The second is the diversity statement and the interview presentation. Neither has a well known body of public examples, and a repository that collects several of each, from people who were willing to share them, is filling a gap that the linked UCSF and EMBO pages do not fill in the same way.

The third is the field-specific context. The bias towards plants and evolution is a limitation for most readers and a feature for readers in that field, where the advice about how to frame a research programme, which journals to treat as central and how to justify a particular agenda is directly transferable. A first-year PhD student in plant ecology has a very different question from a first-year PhD student in particle physics, and the archive answers the first group's question well.

The maintenance picture is modest. The last push to the repository was on 2026-07-17, the repository is not archived, and there are no GitHub releases, which is expected for a collection of PDFs. There is no code to release and no version to speak of. The document set grows when somebody is persuaded to contribute, which is the same mechanism that produced the plants and evolution bias in the first place.

Editorial conclusion

The archive fits a graduate student or early career researcher who is about to write their first research statement or cover letter and wants to see what a successful one looks like in a field they know, and it fits a hiring committee member who wants a reference set to point a candidate at. It is the wrong resource if you need a template with instructions, because there is no guidance in the repository beyond the file naming convention, and it is the wrong resource for anyone whose grant or job application is confidential. Before you contribute anything, read the licensing note: unless you say otherwise, your statement is licensed under CC BY 4.0, which means anyone can reuse and redistribute it with attribution, so decide whether you want your name on a permanently public document before you upload.

Frequently asked questions

Official sources

1. Issues
2. README
3. RILAB/statements on GitHub