It is worth or even necessary to add a README file in every new project. Today we will focus on good practices of writing such a file - with a few examples, and a ready to use template.
Is THE reader that is pushing the boundaries of e-reading. ### Read EPUB, PDF, DOCX (Word) and TXT (Plain text) files! ### Focused Reading, the next step in eBook reading. Rather than having to read walls of text on every page, Focused Reading will let you focus on a few sentences, or even. ReadMe is an easy-to-use tool to help you build out documentation! Each documentation site that you publish on ReadMe is a project. Within a project there is space for documentation, interactive API reference guides, a changelog, and many more features. A remark-based Markdown engine for parsing and rendering ReadMe docs. (In fact, you're looking at it right now, since we've used it to render every doc in this project!) npm install -save @readme/markdown 🧙 Backwards Compatible. Our old engine was based on a format we call 'magic blocks'. A README is a crucial but basic way of documenting your project. While every project should at least have a README, more involved ones can also benefit from a wiki or a dedicated documentation website.
What is a README file?
README (as the name suggests: 'read me') is the first file one should read when starting a new project. It's a set of useful information about a project, and a kind of manual. A README text file appears in many various places and refers not only to programming. We will focus on a programmer's README, though.
example of README for a Bootstrap gem (Ruby On Rails)
Added README file on GitHub appears under the list of files in a repository.
If we work professionally or learn coding, many times we come across the public repositories. We use the libraries made available by other developers as an open source code or we make our contribution to a project, reporting/fixing bugs, and adding new functionalities. Certainly, we use these projects because they just come in handy, and offer a high quality solution. But would we use them if they lacked a user-friendly description, that is, a good README?
Rest assured - you will get to know the feeling of disappointment when finding a potential solution to all of your problems in a library or a project which description is poor, useless or isn't available whatsoever.
What's the use of writing a good README?
I think you can guess it already. A good README is for others to understand what our code includes, and why it's noteworthy. A README file is also essential to retreive a project - on GitHub but also in browsers (e.g. Google).
I am just learning so why should I be bothered about adding a README file? That code is just for me, after all, not for the whole community.
I doubt the code is just for you. And adding a README file is a good move.
README for Junior Devs
OK, now let's check why we should care for our README files since the first project!
Even if the code is just for you, possibly you will come back to it after a while. A good README enables you to relaunch a project - without wasting your time on recalling: What was it all about?
For a budding programmer, GitHub is a calling card. The projects on GitHub are most often our portfolio. When we're at a career stage without a considerable commercial experience or nice-looking non-profit projects, a presentation of our achievements in a form of repositories is one of the best way to get visible to the recruiters. A preparation of several demonstration projects we want to show off during the interview works the best.
If we are just learning and we drop our training projects there, let's pay attention to their good description. Even a non-technical recruiter will be able to recognize the technologies we touched, and check if it goes in line with a candidate's profile he's/she's looking for.
In Polish or in English?
Certainly, in English.Add a project description in English even if your project is in Polish language. The projects realized at the university might be treated as an exeption as they often demand a documentation in Polish. In every other case, describe your projects in English.
README.md - wait, what's it all about?
.md extension comes from a word: markdown. It's a markup language for text formatting. Maybe at first it isn't be obvious but markup has been created to make text creation easier. In HTML language, the most important heading goes with h1 tag. Similarily, we will have # before a heading in our document.
We edit .md files in any text or code editor (Notepad, Sublime, Atom, CS, etc.).
You'll find out more on markdown usage on GitHub, and on dillinger.io you'll find an editor with a preview.
Writing a good README - newbies manual
Open a README.md. file in a new project.
Make sure the file always includes the following elements:
- Titles and internal titles
- Introduction - the project's aim
- Technologies
- Launch
Consider also using additional elements such as:
- Table of contents
- Illustrations
- Scope of functionalities
- Examples of use
- Project status
- Sources
- Other information
That's a lot! There's not so much to say about my project!
There is - but you're not aware of that already.
Titles and internal titles
A title should explain clearly what we have here, and it's usually a project's name - a H1 heading prefaced with #. If a project's name doesn't disclose its content, still it's worth to suggest what it is.
Moreover, the text should include the titles of sections, and - if necessary - the internal titles. To keep our README coherent, we write them similarly in every other document. In our README.md file, the headings should be written down with a multiple of #:
Introduction
Introduction is like a summary. It shouldn't be too long as we don't want to read an essay on a project. We should describe in an interesting manner what's the project aim, and what problems does a given application solve. Two or three sentences are enough in case of a small project.
If it's a training project, mention your incentive. Why did you want to create it? To learn a particular technology? Was it a hackathon project? Was it for a non-profit organization? Is it an application created to memorize the material from workshops or and online course? It's worth mentioning here, without a doubt.
Technologies
Download Attack On Titan Tribute Game Mod
Let's write down the languages we used, the libraries and its versions.
For example:
- Bootstrap 3 or 4
- AngularJS 1.6 / Angular 2+/4/5/6
- PHP 5 or 7
- Python 2.7 or 3.6
- Rails 4 or 5
Why? Firstly, it will be helpful when launching the project in the future. The versions of libraries change, and an inconspicuous change might cause many problems later on. It's good to know the version that has been used when our code was working exactly the way we wanted.
Another thing: recruitment. IT recruiters browse through their candidates' GitHub accounts. Even though they lack a technical knowledge to estimate the quality of solutions, they know the keywords related to their job offers. A description of used technologies might make you stand out among other candidates.
Let's assume there's a multitude of candidates for an internship, and a recruitment time is limited. CVs have been selected, there are two similar candidates, and a last available date in a calendar. The candidates' GitHub accounts include the same number of projects. One of them mentions the technologies in every project. A second candidate doesn't add README files or his/her projects are described poorly. What do you think, which candidate will be invited for an interview?
Launch
How to run a project? Does a project has minimum hardware requirements?
We mentioned the libraries and their versions earlier. If necessary, technologies, launch, and hardware requirements can be merged together. But if we split it into two subsections, it's worth to focus here specifically on launching a project. When we have a website or application, it can concerned setting up a local environment, a link to GitHub pages or deployed application on Heroku. Do we need input data? If so, in what format?
Let's focus on other elements that can improve our README.
Table of contents
Table of contents comes in handy in case of extensive documentation. It can work as a simple list with the links to headings.
GitHub automatically adds id to headings according to the content inside a tag (spaces will become a sign '-'). Therefore, the links are constructed this way: https://github.com/user/repo-name#header-name. It enables to create a simple table of contents, e.g.:
And it will look like:
Illustrations
GitHub allows for graphics in README. A technical documentation doesn't need to be pretty but legible and understandable. The illustrations aren't necessary - nevertheless, they can aesthetical value to our project. You can show an application's logo, diagrams, schemes, exemplary screenshot. Maybe an illustrated manual is something you want?
Create a file in your repository, and add an image there. Use a file path to display it using: . You can use the images from beyond you repository if they're publicly available - but there's always a risk that the owner of these sources would delete them from his/her domain, and they'll disappear from your documentation: 
Example: In my README file, I want to place a block schema that would illustrate how an algorithm works. I keep my schema.jpg file in a directory called images. To display it in my documentation, I will use a code:
Scope of functionalities
There's no always use in describing the scope of functionalities. For a website-visiting card or a simple application of to-do type, the list of functionalities is an excess of form.
On the other hand, a seemingly simple project such as to-do list can be extended with many interesting options we can be proud of: users register, recording and classifying the tasks according to date, adding commentaries to the tasks or data export to the files.
Examples of use
In case of reusable code or your own library, providing a manual how to use our project might be necessary. It can work as a fragment of code:
which will be displayed as:
The project status
It's worth to add a project status - especially if the project is still being developed. If it's our library, let's mention planned changes, direction of development or to emphasize we're done with its development.
Sources
Should we add information when our project was based on a tutorial or we got inspired with a given task? Yes, sure.
I don't get the doubts in that matter. There's nothing embarassing in the fact that we learn from various sources and we document our progress. We complete many tutorials, choose learning material. A thoughless copying without providing changes in it - and without learning at all - mostly doesn't happen.
If our code was based on somebody else's code, we should add such information.
Maybe we use an old tutorial - for example, we write an application with Rails 3 tutorial. From scratch, in accordance with Rails 5 version, using new framework mechanisms. Certainly, it's worth mentioning here.
When our code was only inspired by another solution/an application, you can mention it and write the way you got inspired, what changes you made, what functionalities were developed.
When we solve the sets of exercises, it's worth adding where others can find their description. If we will want to come back to these sources, the link will come up easily. This way, the author who shared his/her knowledge is, spent his/her time to prepare and share this material is also respected.
Other information
Information on the author, contact, www and social media links, a type of license under which the code is made available or the information on how to contribute to a project - these are only the examples of what can be added to your project.
A good, legible README
The suggestions above are mine. The most importaint point is just legibility. A thorough documentation make your repository shine in front of the recruiters and other programmers. There are many approaches to writing a good README. Take a look at the following examples:
- Node-chat – a simple description, screenshot of the application, examples of use
- WebApp – a splendid example of description provided for a landing page type of website and application using API. Description how it works, screenshots, technologies employed in this solution, additional information on functionalities that will be implemented
- Pomolectron – we have a logo, the screenshots, an instruction on installation and a description how it works
- Git point – exemplary Android application. A table of content makes navigation easier, the screenshots, mentioned functionalities, and information how to support application's development
README template
I leave you here an example of README.md file template you can download. Take a look at its formatting, and copy a raw version to your README.md file.
The article is also available in Polish on Flynerd.pl blog.
Attack On Titan Tribute Download
A READMEfile contains information about other files in a directory or archive of computer software. A form of documentation, it is usually a simple plain text file called Read Me, READ.ME,[1]README.TXT,[2][1]README.md[1] (for a text file using markdown markup), README.1ST[1] – or simply README.[1]
The file's name is generally written in uppercase letters. On Unix-like systems in particular this makes it easily noticed – both because lowercase filenames are more common, and because traditionally the ls command sorts and displays files in ASCII-code order, so that uppercase filenames appear first.[nb 1]
Contents[edit]
The contents typically include one or more of the following:
- Configuration instructions
- Installation instructions
- Operating instructions
- A file manifest (list of files included)
- Copyright and licensing information
- Contact information for the distributor or programmer
- Known bugs[3]
- Troubleshooting[3]
- Credits and acknowledgments
- A changelog (usually for programmers)
- A news section (usually for users)
History[edit]
It is unclear when the convention began, but there are examples dating back to the mid 1970s.[4][5][6][7][8][9][1][better source needed] Early Macintosh system software installed a Read Me on the startup disk, and they commonly accompanied third-party software.
example of README for a Bootstrap gem (Ruby On Rails)
Added README file on GitHub appears under the list of files in a repository.
If we work professionally or learn coding, many times we come across the public repositories. We use the libraries made available by other developers as an open source code or we make our contribution to a project, reporting/fixing bugs, and adding new functionalities. Certainly, we use these projects because they just come in handy, and offer a high quality solution. But would we use them if they lacked a user-friendly description, that is, a good README?
Rest assured - you will get to know the feeling of disappointment when finding a potential solution to all of your problems in a library or a project which description is poor, useless or isn't available whatsoever.
What's the use of writing a good README?
I think you can guess it already. A good README is for others to understand what our code includes, and why it's noteworthy. A README file is also essential to retreive a project - on GitHub but also in browsers (e.g. Google).
I am just learning so why should I be bothered about adding a README file? That code is just for me, after all, not for the whole community.
I doubt the code is just for you. And adding a README file is a good move.
README for Junior Devs
OK, now let's check why we should care for our README files since the first project!
Even if the code is just for you, possibly you will come back to it after a while. A good README enables you to relaunch a project - without wasting your time on recalling: What was it all about?
For a budding programmer, GitHub is a calling card. The projects on GitHub are most often our portfolio. When we're at a career stage without a considerable commercial experience or nice-looking non-profit projects, a presentation of our achievements in a form of repositories is one of the best way to get visible to the recruiters. A preparation of several demonstration projects we want to show off during the interview works the best.
If we are just learning and we drop our training projects there, let's pay attention to their good description. Even a non-technical recruiter will be able to recognize the technologies we touched, and check if it goes in line with a candidate's profile he's/she's looking for.
In Polish or in English?
Certainly, in English.Add a project description in English even if your project is in Polish language. The projects realized at the university might be treated as an exeption as they often demand a documentation in Polish. In every other case, describe your projects in English.
README.md - wait, what's it all about?
.md extension comes from a word: markdown. It's a markup language for text formatting. Maybe at first it isn't be obvious but markup has been created to make text creation easier. In HTML language, the most important heading goes with h1 tag. Similarily, we will have # before a heading in our document.
We edit .md files in any text or code editor (Notepad, Sublime, Atom, CS, etc.).
You'll find out more on markdown usage on GitHub, and on dillinger.io you'll find an editor with a preview.
Writing a good README - newbies manual
Open a README.md. file in a new project.
Make sure the file always includes the following elements:
- Titles and internal titles
- Introduction - the project's aim
- Technologies
- Launch
Consider also using additional elements such as:
- Table of contents
- Illustrations
- Scope of functionalities
- Examples of use
- Project status
- Sources
- Other information
That's a lot! There's not so much to say about my project!
There is - but you're not aware of that already.
Titles and internal titles
A title should explain clearly what we have here, and it's usually a project's name - a H1 heading prefaced with #. If a project's name doesn't disclose its content, still it's worth to suggest what it is.
Moreover, the text should include the titles of sections, and - if necessary - the internal titles. To keep our README coherent, we write them similarly in every other document. In our README.md file, the headings should be written down with a multiple of #:
Introduction
Introduction is like a summary. It shouldn't be too long as we don't want to read an essay on a project. We should describe in an interesting manner what's the project aim, and what problems does a given application solve. Two or three sentences are enough in case of a small project.
If it's a training project, mention your incentive. Why did you want to create it? To learn a particular technology? Was it a hackathon project? Was it for a non-profit organization? Is it an application created to memorize the material from workshops or and online course? It's worth mentioning here, without a doubt.
Technologies
Download Attack On Titan Tribute Game Mod
Let's write down the languages we used, the libraries and its versions.
For example:
- Bootstrap 3 or 4
- AngularJS 1.6 / Angular 2+/4/5/6
- PHP 5 or 7
- Python 2.7 or 3.6
- Rails 4 or 5
Why? Firstly, it will be helpful when launching the project in the future. The versions of libraries change, and an inconspicuous change might cause many problems later on. It's good to know the version that has been used when our code was working exactly the way we wanted.
Another thing: recruitment. IT recruiters browse through their candidates' GitHub accounts. Even though they lack a technical knowledge to estimate the quality of solutions, they know the keywords related to their job offers. A description of used technologies might make you stand out among other candidates.
Let's assume there's a multitude of candidates for an internship, and a recruitment time is limited. CVs have been selected, there are two similar candidates, and a last available date in a calendar. The candidates' GitHub accounts include the same number of projects. One of them mentions the technologies in every project. A second candidate doesn't add README files or his/her projects are described poorly. What do you think, which candidate will be invited for an interview?
Launch
How to run a project? Does a project has minimum hardware requirements?
We mentioned the libraries and their versions earlier. If necessary, technologies, launch, and hardware requirements can be merged together. But if we split it into two subsections, it's worth to focus here specifically on launching a project. When we have a website or application, it can concerned setting up a local environment, a link to GitHub pages or deployed application on Heroku. Do we need input data? If so, in what format?
Let's focus on other elements that can improve our README.
Table of contents
Table of contents comes in handy in case of extensive documentation. It can work as a simple list with the links to headings.
GitHub automatically adds id to headings according to the content inside a tag (spaces will become a sign '-'). Therefore, the links are constructed this way: https://github.com/user/repo-name#header-name. It enables to create a simple table of contents, e.g.:
And it will look like:
Illustrations
GitHub allows for graphics in README. A technical documentation doesn't need to be pretty but legible and understandable. The illustrations aren't necessary - nevertheless, they can aesthetical value to our project. You can show an application's logo, diagrams, schemes, exemplary screenshot. Maybe an illustrated manual is something you want?
Create a file in your repository, and add an image there. Use a file path to display it using: . You can use the images from beyond you repository if they're publicly available - but there's always a risk that the owner of these sources would delete them from his/her domain, and they'll disappear from your documentation: 
Example: In my README file, I want to place a block schema that would illustrate how an algorithm works. I keep my schema.jpg file in a directory called images. To display it in my documentation, I will use a code:
Scope of functionalities
There's no always use in describing the scope of functionalities. For a website-visiting card or a simple application of to-do type, the list of functionalities is an excess of form.
On the other hand, a seemingly simple project such as to-do list can be extended with many interesting options we can be proud of: users register, recording and classifying the tasks according to date, adding commentaries to the tasks or data export to the files.
Examples of use
In case of reusable code or your own library, providing a manual how to use our project might be necessary. It can work as a fragment of code:
which will be displayed as:
The project status
It's worth to add a project status - especially if the project is still being developed. If it's our library, let's mention planned changes, direction of development or to emphasize we're done with its development.
Sources
Should we add information when our project was based on a tutorial or we got inspired with a given task? Yes, sure.
I don't get the doubts in that matter. There's nothing embarassing in the fact that we learn from various sources and we document our progress. We complete many tutorials, choose learning material. A thoughless copying without providing changes in it - and without learning at all - mostly doesn't happen.
If our code was based on somebody else's code, we should add such information.
Maybe we use an old tutorial - for example, we write an application with Rails 3 tutorial. From scratch, in accordance with Rails 5 version, using new framework mechanisms. Certainly, it's worth mentioning here.
When our code was only inspired by another solution/an application, you can mention it and write the way you got inspired, what changes you made, what functionalities were developed.
When we solve the sets of exercises, it's worth adding where others can find their description. If we will want to come back to these sources, the link will come up easily. This way, the author who shared his/her knowledge is, spent his/her time to prepare and share this material is also respected.
Other information
Information on the author, contact, www and social media links, a type of license under which the code is made available or the information on how to contribute to a project - these are only the examples of what can be added to your project.
A good, legible README
The suggestions above are mine. The most importaint point is just legibility. A thorough documentation make your repository shine in front of the recruiters and other programmers. There are many approaches to writing a good README. Take a look at the following examples:
- Node-chat – a simple description, screenshot of the application, examples of use
- WebApp – a splendid example of description provided for a landing page type of website and application using API. Description how it works, screenshots, technologies employed in this solution, additional information on functionalities that will be implemented
- Pomolectron – we have a logo, the screenshots, an instruction on installation and a description how it works
- Git point – exemplary Android application. A table of content makes navigation easier, the screenshots, mentioned functionalities, and information how to support application's development
README template
I leave you here an example of README.md file template you can download. Take a look at its formatting, and copy a raw version to your README.md file.
The article is also available in Polish on Flynerd.pl blog.
Attack On Titan Tribute Download
A READMEfile contains information about other files in a directory or archive of computer software. A form of documentation, it is usually a simple plain text file called Read Me, READ.ME,[1]README.TXT,[2][1]README.md[1] (for a text file using markdown markup), README.1ST[1] – or simply README.[1]
The file's name is generally written in uppercase letters. On Unix-like systems in particular this makes it easily noticed – both because lowercase filenames are more common, and because traditionally the ls command sorts and displays files in ASCII-code order, so that uppercase filenames appear first.[nb 1]
Contents[edit]
The contents typically include one or more of the following:
- Configuration instructions
- Installation instructions
- Operating instructions
- A file manifest (list of files included)
- Copyright and licensing information
- Contact information for the distributor or programmer
- Known bugs[3]
- Troubleshooting[3]
- Credits and acknowledgments
- A changelog (usually for programmers)
- A news section (usually for users)
History[edit]
It is unclear when the convention began, but there are examples dating back to the mid 1970s.[4][5][6][7][8][9][1][better source needed] Early Macintosh system software installed a Read Me on the startup disk, and they commonly accompanied third-party software.
In particular, there is a long history of free software and open-source software including a README file; the GNU Coding Standards.[10] encourage including one to provide 'a general overview of the package'.
Since the advent of the web as a de facto standard platform for software distribution, many software packages have moved (or occasionally, copied) some of the above ancillary files and pieces of information to a website or wiki, sometimes including the README itself, or sometimes leaving behind only a brief README file without all of the information required by a new user of the software.
In more recent times, the popular GitHub proprietary Git repository[11] strongly encourages a README file - if one is included in the main (top-level) directory, it is automatically presented on the main web page. While traditional plain text is supported, various different file extensions and formats are also supported,[12] and conversion to HTML takes account of the file extension of the file – in particular a 'README.md' file would be treated as a GitHub Flavored Markdown file.
As a generic term[edit]
The expression 'readme file' is also sometimes used generically, for files with a similar purpose.[citation needed] For example, the source code distributions of many free software packages, especially those following the Gnits Standards or those produced with GNU Autotools, include a standard set of readme files:
README | General information |
AUTHORS | Credits |
THANKS | Acknowledgments |
CHANGELOG | A detailed changelog, intended for programmers |
NEWS | A basic changelog, intended for users |
INSTALL | Installation instructions |
COPYING / LICENSE | Copyright and licensing information |
BUGS | Known bugs and instructions on reporting new ones |
CONTRIBUTING / HACKING | Guide for prospective contributors to the project |
Other files commonly distributed with software include a FAQ and a TODO file listing possible future changes.
See also[edit]
Notes[edit]
- ^This is often no longer the case – but LC_ALL=C ls will show the older behavior.
References[edit]
- ^ abcdefAbdelhafith, Omar (2015-08-13). 'README.md: History and Components'. Archived from the original on 2020-01-25. Retrieved 2020-01-25.
- ^Raymond, Eric Steven (1996). The New Hacker's Dictionary. MIT Press. pp. 378–79. ISBN978-0-26268092-9.
Hacker's-eye introduction traditionally included in the top-level directory of a Unix source distribution, containing a pointer to more detailed documentation, credits, miscellaneous revision history, notes, etc. […] When asked, hackers invariably relate the README convention to the famous scene in Lewis Carroll's Alice's Adventures In Wonderland in which Alice confronts magic munchies labeled 'Eat Me' and 'Drink Me'.
- ^ abManes, Stephen (November 1996). 'README? Sure--before I buy!'. PC World. 14 (11): 366.
- ^'PDP-10 Archive: decus/20-0079/readme.txt from decus_20tap3_198111'. pdp-10.trailing-edge.com. 1974-11-27. Retrieved 2018-03-03.
[README.TXT is the DOC file for SPICE/SINC/SLIC] This failsafe tape contains the circuit analysis programs SPICE SINC and SLIC described in the Applications Software Bulletin Volume 4. requirements: SPICE requires FORTRAN-10 version 4 because of its use of Right adjusted Holerith data. Executes in about 47K. […] it also includes this file, the FOROTS to go with the SAVes and the source for SECOND.MAC, the timing routine. SPICE is broken into three parts: 1SPICE.FOR, 2 and 3. There is a printed document to describe each of the programs. These are included in the DECUS packet. The documentation and programs were origionally developed by the E.E. department of the Univ. of Calif. at Berkeley on a CDC 6400. Except to convert the FORTRAN to the DECsystem-10 no changes have been made to the programs. For the test data SLIC and SINC have shown a slight variation with respect to the 6400, SPICE shows no variation. Good luck! Ashley Grayson 27-NOV-74 [end of README.TXT]
- ^'DECUS 10-LIB-4 Contains 10-210 through 10-241, except 10-223'. pdp-10.trailing-edge.com. 1975-03-27. Retrieved 2018-03-03.
The files on this FAILSAFE tape constitute the UCI LISP system. They are for the most part documented in the UCI LISP Manual, available from the Department of Information and Computer Science at the University of California, Irvine, California.
[1] - ^'Programmer's Workbench /sys/source/lex/README'. July 1977. Retrieved 2020-01-25.
- ^'Unix 7th edition /usr/doc/README'. 1979. Retrieved 2020-01-25.
- ^'First 32bit BSD usr/doc/README'. March 1980. Retrieved 2020-01-25.
- ^Langemeier, Jeff (2011-07-29). 'Re: Origin of README'. Retrieved 2020-01-25 – via Stackexchange.
[…] they had READMEs (actual physical printed files) for all of their punch cards and mag tape and pretty much anything else that was a 'program'. At that time you really needed one because of the labourous process that was involved with getting the created, ran, and everything else. These READMEs sometimes also included the actual printouts of how the punch cards were supposed to be punched as a form of error checking and debugging. The convention apparently also follows the old system in that with all the punch cards a 'reem' of paper was attached with the statement README in caps printed on it, this had all of the instructions for use and loading of the punch cards into the system. For a time reference, this would have been in the 60s. […]
- ^'GNU Coding Standards: Releases'. www.gnu.org. Retrieved 2018-03-03.
- ^'Code-sharing site Github turns five and hits 3.5 million users, 6 million repositories'. TheNextWeb.com. 2013-04-11. Retrieved 2013-04-11.
- ^'Markup'. GitHub. GitHub. 2014-12-25. Retrieved 2015-02-08.
Further reading[edit]
- Johnson, Mark (1997-02-01). 'Building a Better ReadMe'. Technical Communication. Society for Technical Communication. 44 (1): 28–36. JSTOR43089849.[2][3]
- Rescigno, Jeanne (August 1997). 'Hypertext good choice for README files'. Technical Communication. Society for Technical Communication. 44 (3): 214. JSTOR43089876.
- Livingston, Brian (1998-09-14). 'Check your Readme files to avoid common Windows problems'. InfoWorld. Vol. 20 no. 37. InfoWorld Media Group, Inc. p. 34. Archived from the original on 2006-11-18. Retrieved 2019-06-04.[4]
- Benjamin, Andrew (1996-09-15) [1993]. Written at Department of Philosophy, University of Warwick, UK. Guédon, Jean-Claude (ed.). 'Readme: Writing Notes - Meditations on the temporality of writing'. Surfaces (Electronic journal) (in English and French). Université de Montréal, Montreal (Quebec), Canada: Les Presses de l'Université de Montréal. III (12): 1–12. ISSN1188-2492. Archived from the original on 2006-02-20. Retrieved 2019-06-04.[5]
This article is based in part on the Jargon File, which is in the public domain.
