-
-
Notifications
You must be signed in to change notification settings - Fork 291
Create a guide for migration of docs #544
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from 3 commits
844e6c0
22a6038
22ea38a
25be999
4d72d09
13e1a6d
1d80c13
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,34 @@ | ||
# How to Migrate Documentation - Step-by-Step Process | ||
|
||
Migrating documentation is often crucial when reorganizing any project. As such, below is a list of instructions and guidelines to aid you when embarking on the migration journey. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this needs a bit of motivation. Something like that there is a lot of good stuff out there. You may find a piece of writing that covers a topic you want documented very nicely. But different projects, repositories, groups of people - for various reasons - put their work under free but different and possibly incompatible licenses, which may preclude using it for our purposes straight away. (Please don't take this verbatim...) |
||
|
||
1. **Licensing** | ||
zmitchell marked this conversation as resolved.
Show resolved
Hide resolved
|
||
1. Familiarize yourself with the licenses governing the documentation you intend to migrate. | ||
2. Verify if the license of the documentation is compatible with this project's current license. | ||
JeremiahSecrist marked this conversation as resolved.
Show resolved
Hide resolved
|
||
3. If the licenses align, proceed with the migration. Otherwise, follow the steps below. | ||
zmitchell marked this conversation as resolved.
Show resolved
Hide resolved
|
||
4. Identify the file and determine all contributors to the documentation (typically using blame or a co-owners document). | ||
5. Contact all contributors, requesting permission to migrate the document to the new license. | ||
6. Await responses from all recipients and obtain explicit approval from each contributor before proceeding. | ||
7. If agreement from all contributors cannot be obtained, consider alternative solutions to avoid licensing conflicts, such as: | ||
- A full rewrite of the document. | ||
- Rewriting the areas of specific contributors who did not reply or approve. | ||
|
||
2. **Documentation Assessment** | ||
zmitchell marked this conversation as resolved.
Show resolved
Hide resolved
|
||
1. Perform a thorough review of the existing documentation. | ||
2. Assess the scope, relevance, and quality of the documentation in relation to the migration location. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's not clear to me what "quality of the documentation in relation to the migration location" means. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This still needs to be addressed |
||
3. Consider factors such as: | ||
- Completeness | ||
- Accuracy | ||
- Organization | ||
- Readability | ||
|
||
3. **Version Control and Branching Strategy** | ||
1. Determine the appropriate branch or repository that contains the most up-to-date or relevant information about the project. In some situations, one might migrate the wrong version if the incorrect branch is specified. | ||
zmitchell marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
5. **Validation and Quality Assurance Post Migration** | ||
zmitchell marked this conversation as resolved.
Show resolved
Hide resolved
|
||
1. Ensure consistency in the format and structure of the migrated documentation. | ||
2. Consider factors like headings, sections, code formatting, tables, and diagrams. | ||
3. Perform a thorough validation and quality assurance process before finalizing the migration. | ||
zmitchell marked this conversation as resolved.
Show resolved
Hide resolved
|
||
4. Review the migrated documentation for accuracy, completeness, and adherence to desired standards. | ||
5. Validate code snippets, links, images, and references included in the migrated content. | ||
6. Conduct usability testing to gather feedback from users and iterate on the documentation based on their input. | ||
JeremiahSecrist marked this conversation as resolved.
Show resolved
Hide resolved
|
Uh oh!
There was an error while loading. Please reload this page.