-
Notifications
You must be signed in to change notification settings - Fork 9
contrib guide - initial draft #8
contrib guide - initial draft #8
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Loquacity - thanks for this header breakdown.
This would be generic content for a Contributor Guide to all projects within the Good Docs Project, yeah?
I should then also add headers specific to the Base Template Contributor Guide, inside this folder, isn't it?
Yeah, this is contributor guide content which applies to the entire project. The base template content needs to go in one of the two other files in this folder. Just create your own fork and branch and start a new PR. |
Considerations for reviewers:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one observation about Glossary git terms that you might want to consider before finalising the PR.
Pulled language up a level, removed glossary. |
The |
|
||
Note that pull requests in different repositories within the Good Docs Project require different levels of review rigor. | ||
For example, the `incubator` repo has a much lower standard of code quality than the `templates` repo. | ||
For a full explanation of our review standards, see [insert.link.here]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see [insert.link.here].
Specific page in mind? Or this a followup?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there was work being done on review standards in a gdoc, but I'm not sure it has a home on the site yet.
Assertively enhance functional solutions for synergistic opportunities. Proactively expedite cross-media synergy whereas cutting-edge services. Appropriately embrace principle-centered leadership via leveraged infomediaries. Competently negotiate top-line products through 24/365 experiences. Professionally matrix goal-oriented processes and bleeding-edge experiences. | ||
Like most open source projects, there are always tasks to do. | ||
For the list of issues, see [https://github.com/thegooddocsproject/templates/issues](The Good Docs Project template issues). | ||
Look for issues with a `good first issue` tag if you want something small to start on. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💯 like this idea, just not sure we are tagging things appropriately and we should link to the tags.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I checked, there are a few "good first issue" tags in the repo, but I agree that we should probably review our practices around this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added some additional thoughts on content
I went with forks because if you don't have any rights in an org, it's the only way to create a PR. So if you're coming to TGDP for the first time, it's unlikely you'll have the perms to be able to do a branch straight up. Also, it's the least destructive way for a novice to interact with git, to my way of thinking, even if branches are easier to manage. |
@Loquacity yeah I realized post writing the comments that |
Initial draft of the contributors' guide.
Partial https://github.com/thegooddocsproject/planning/issues/6