Hey @tkimnguyen, it sounds good. I am working on it right now I will let you know how the process goes.
In addition, I found out that the requirement.txt in https://github.com/plone/papyrus is supposed to pin the version of the zc.buildout since it might create conflict with the pinned version of it in buildout.cfg. Should I make change to it and ask for permission to push it to the 5.0 branch?
As you can see, the link I created is not there anymore. Can you give some suggestion on what I should do to resolve this? I don't really know where to ask
@nctl144 I would very much like to collaborate with you on this project, as I am also trying to automate deployment of a Plone instance on Digital Ocean myself. Do you have an open PR or branch for this work? I'd love to review it, take it for a test drive, and contribute to it.
This is likely due to Sphinx caching. Sphinx builds only those files that did not previously exist or that have changed. If you built your docs, then added the new file and did not edit https://docs.plone.org/manage/deploying/production/restarts.html then I would assume this navigation did not get rebuilt for this section. You could do a make clean or delete the build directory, and then rebuild the docs, and I assume it will show up.
Hey @stevepiercy, I have solved that problem a few days ago but thank you so much for your help
I am working on this idea here, which I will create a pull request as soon as I have done checking my grammar and format. Please let me know if you have any suggestion xD.
Can you also give me your github username so I can add you later?
I finally have submitted my pull request to the documentation. Thank you guys so much for the encouragement and support
Probably there's still a lot to do. Can you guys give me feedback on my work and suggest me what to work on next...
I can see on my pull request that the travis check has failed since the buildout generated version conflict. Is there any idea...
Here is the preview of the page I worked on.
@nctl144 Thanks for your contribution. Hopefully someone at Plone Open Garden this week sprint can review it
I believe that for pull requests it's ok to squash commits to lessen noise in the commit history (by interactive rebasing and force pushing to rewrite your branches history).
@datakurre Yes it is definitely better to follow the rule of thumb "merge upstream rebase downstream" to keep the commit history clean
Thank you so much for your encouragement. I could not think of this idea if you did not mention it :))
Since I have access to your repo, I will review the suggestions already on the PR at https://github.com/plone/documentation/pull/821, edit, and push some commits to your repo. I think that will update the PR, too.
One of our sprint topics was the various installer & try-out-Plone methods. We counted about 14 methods and will be streamlining what we initially present and will try to determine what the person is likely to need.