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

Minor doc fixes #9

Closed
wants to merge 4 commits into
base: releases
from

Conversation

Projects
None yet
2 participants
@paultcochrane
Contributor

paultcochrane commented Feb 10, 2018

This PR improves sentence flow in the documentation a bit and fixes other minor issues. I've split up the commits so that they can be cherry-picked if so desired. For instance, I've made the assumption that American spelling should be used (as is often the case with technical documentation); however, I suspect you might have wanted the Canadian spelling (which seems to often follow the British spelling conventions), hence cherry-picking might be the best thing. If you want these commits rolled into one commit so that the history is nicer, I don't have a problem with doing that and can resubmit the PR.

yanick and others added some commits Sep 23, 2015

v0.27
  - Remode  'README.pod' from distribution. [GH#6]

  [ STATISTICS ]
    - code churn: 4 files changed, 62 insertions(+), 126 deletions(-)
@paultcochrane

This comment has been minimized.

Contributor

paultcochrane commented Feb 10, 2018

Just a side question: after having looked at the repository and its branches, I got the impression that one should base pull requests off the master branch rather than the releases branch. Is that correct? Also: would contributor documentation be helpful? That way there could be a guide for people who want to set up a development environment and submit patches, and they can thus submit PRs in a form that makes them easier for you to merge. Just a thought :-)

@yanick

This comment has been minimized.

Contributor

yanick commented Feb 10, 2018

I got the impression that one should base pull requests off the master branch rather than the releases branch. Is that correct?

If you can, basing the PRs out of master is prefered. But since I use Dist::Zilla in a rather, ah, hard-core manner, I recognize that it's not everyone's cup of tea and I'm perfectly willing to port the PRs from releases back to master. :-)

@yanick

This comment has been minimized.

Contributor

yanick commented Feb 10, 2018

would contributor documentation be helpful? That way there could be a guide for people who want to set up a development environment and submit patches, and they can thus submit PRs in a form that makes them easier for you to merge. Just a thought :-)

Sure! Bear in mind, though, that Dancer 1 is superseded by Dancer 2, so contributions to this module are expected to slowly dwindle to nothing. But if you feel like it, hey, more documentation is always good documentation. :-) I'm even pretty sure there is a Dist::Zilla plugin somewhere that would provide you with a decent template for it too.

@yanick

This comment has been minimized.

Contributor

yanick commented Feb 10, 2018

I've split up the commits so that they can be cherry-picked if so desired.

That's the way I prefer it, thank you so much. ^.^ That way, I can always merge it all like a savage if I feel like it, but if there any specific decision I don't agree with, it's much easier to not pick it up as-is.

yanick added a commit that referenced this pull request Feb 10, 2018

merge branch 'pr/9'
 - Improve English flow of the POD. [GH#9, Paul Cochrane]

Fixes #9
@yanick

This comment has been minimized.

Contributor

yanick commented Feb 10, 2018

Merged to master, thanks!

@yanick yanick added this to the v0.28 milestone Feb 10, 2018

@yanick yanick closed this Feb 10, 2018

@paultcochrane paultcochrane deleted the paultcochrane:pr/minor-doc-fixes branch Feb 11, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment