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
When to send a pull request #14
Comments
I agree. At the moment, my priority is to ensure that anyone joining the project is already aware of what is underway. Once we've discussed among the core translation team on how to proceed, there should be less confusion on which lessons are already in progress. I recommend frequently committing work in progress as well (at least locally), when you push to your repo or send a PR is up to you. I think minor changes are okay to send to the main repo now but when we have more contributors it would be best to do each lesson/section at once (maybe this would be a good time for others to review changes). I would suggest the following times to send a PR:
|
A related question is "when is the best time to generate the webpage?" This is not such an issue for the files that will only be found in the git repo. It may be best to wait until major changes have been double-checked before pushing updates to the webpages (it's also laborious to do this too frequently). However, mistakes or ambiguous sections may be easier for others to see and notify us if they can be seen in the webpages. Although, at the moment, most of the webpages still in English or my "demo translation" with many mistakes so I don't mind to push changes to fix this. |
I agree, web page should be (re-)made only after major changes have been made to the translation. There's probably an easier way to generate/update the web page automatically (perhaps Travis?), which is probably something we should have a look at. |
If there is a develop branch, I want to see the any latest version of web page. Anyway, double checking is a good thing. |
It may be easier to check the documents as a webpage for some people. However, it is not a trivial process to push changes to the webpages. Please note that the markdown "md" files can also be viewed on GitHub. At the moment, there is no "development branch". There is a separate branch for Japanese. This entire repository is for development purposes (as is the swcarpentry-i18n repo) as these are eventually intended to be merged with the main swcarpentry lessons. Please note that only one branch (gh-pages by default) can be rendered as a webpage for each repository. We use the master branch for submodules for each language but are still limited to one version of the webpages being generated at any one time. |
I think we've agreed that we should only send PR for relatively major changes |
There are recommendations for this. Generally, we will wait until changes are significant enough to get a second opinion. Anyone can still send minor corrections but I won't merge large sections if they're still a work in progress. |
I'm happy right now for you @TomKellyGenetics to pull all the changes from my fork every so often, but I feel like we should be making pull requests for larger changes (e.g. finished a section/chapter), rather than PR for small, incremental changes (e.g. edited a few lines here and there).
This doesn't mean that the translators shouldn't be committing unless they've translated a whole section (in fact, people should be committing as frequently as they should), but only send a pull request when they are happy with their progress.
Unless the changes in the forked repo are essential for the others to know about immediately, I think PR can wait for however long time.
The text was updated successfully, but these errors were encountered: