Thanks for the explanation of your workflow! It's insightful and interesting how we do many similar things, but in a different way.
Let me first walk you through the workflow we use, so we can see the similarities, and then figure out the next steps for the long-term.
If I wanted to edit something in the Fedora Docs, let's say the Fedora 28 Release Notes, I would do:
1) Fork the source repository and make a local copy. How:
I would go to the source repository: https://pagure.io/fedora-docs/release-notes/ (All source repositories are listed here: https://pagure.io/fedora-docs/docs-fp-o)
I would click at "Fork" at the top-right corner which would create my own copy of the repository on the server.
Then I would open my fork in the web browser https://pagure.io/fork/asamalik/fedora-docs/release-notes and copied the "SSH" URL under Source GIT URLs.
In my terminal, I would clone my fork by:
$ git clone ssh://git@xxxxxxxxx/forks/asamalik/fedora-docs/release-notes.git
Since I want to do changes for Fedora 28, I need to switch to the f28 branch. (A list of all branches is on the web UI we've already seen, at the right side. Branch names should be intuitive, so after seeing "f27, f28, master, etc.", I've guessed that f28 is the right one.)
$ git checkout f28
2) Do the edits in the local copy of the fork. How:
I would edit the .adoc files I want to edit. I would do multiple changes at once, that's fine. However, I would try to do changes of one "type" for a lack of a better term. For example, grammar edits. A complete rewrite of one page or a few related pages. Or adding some missing content. etc.
To preview my changes, I could use the instructions at the README.md which says I should run "./build.sh && ./preview.sh".
3) Commit and push the changes to the fork on the server. How:
After I'm done with the changes I would commit them (register the changes with the local copy of the fork):
$ git add .
$ git commit -m "describing my change here in about 8 words"
And then pushing the commits (applying the local changes to the fork on the server, so anyone can see it)
4) Send a PR. How:
Now I want to apply the changes I have in my fork on the server to the original repository. This is done by submitting a PR (pull-request, a request to the owner of the original repository to accept the changes I have made).
For that, I would open the original repository: https://pagure.io/fedora-docs/release-notes , click on the "Pull Requests" tab, then on the blue "File Pull Request" drop-down, and select my fork and the branch I have edited. In this case that would be "[asamalik/release-notes] [f28]".
Now that I've selected the PR goes from asamalik/release-notes f28, I need to make sure it goes to the right branch in the target repository. I need to select "f28" in the dropdown that now probably says "master".
Now, I need to add a title and a description of what and why I've done.
I can also review the changes by clicking at "Files Changed" at the very bottom.
Finally, click "Create" and the PR has been submitted.
5) Someone needs to do a review. How:
Someone will check the changes and provides feedback. I can use the built-in discussion to discuss the changes with the reviewer. The reviewer either merges the PR, or asks for additional changes.
Good thing here is that I don't have to make my changes perfect at the first try. I can even ask for suggestions in the PR itself. And also, multiple different people can provide feedback. That's how we can scale across many people in the community.
6) Just sometimes, making additional changes. How:
I would go to the local copy of my fork, do the changes (step 2 above), and commit and push the changes (step 3 above). They will be applied automatically to the PR, because I have modified the same branch.
So, that's it.
Leslie, I have found three major differences between your workflow and the one I've just described:
1) The way we do the preview. We have provided tooling to preview the whole repository at once. That's useful for internal links, for example. Let me know if I can help with getting that work.
2) One change at a time vs. multiple changes at once. We do multiple changes at once, and provide feedback on all of them. It's always possible to say something like "I like the first five changes you've made, but I would do the last one differently". And then we can iterate. Which brings me to the third point:
3) We iterate. We don't expect things to be perfect at the first try. That's why we don't distinguish between a "review before submitting a PR" and the PR itself. We just submit the PR, get a feedback there, and if needed, we can do another set of changes based on the feedback.
This way, we don't need to send anything via email to individual people. Anyone in the community can provide feedback to the changes. And multiple people with the sufficient permissions can merge the changes.
What do you think? Does that make sense?
And as I said earlier, I'm happy to walk you through the whole process over a video call + screen share. We just need to figure out the best time as I'm in Europe, so it would probably be your morning and my evening.
Cheers!
Adam
On Thu, Aug 23, 2018 at 6:35 PM Leslie S Satenstein <lsatenstein@xxxxxxxxx> wrote:
Please distinguish editing from writing. This is what I do for the editing.Insure asciidoctor is installed, as well as libreoffice and gitgit clone a repository.enable git and create a branch of said repository I will use as an example, the release notesFor each directory within the release notes repository, create a libreoffice document directoryfor each *.adoc in each directory, run the followingcat ~/bin/adoc
#!/bin/bash
if [ $# = 0 ];
then
echo "command is $0 asciidoc.adoc "
echo "output to /tmp/asciidoc.html "
echo "Also creates a /tmp/x.sh pointing vim to the asciidoc.adoc"
exit 0
fi
bn=$(basename $1 .adoc)
dn=$(pwd)
inadoc=${bn}.adoc
asciidoctor --out-file /tmp/${inadoc}.html.odt ${bn}.adoc 2>/tmp/${inadoc}.errs
echo "vim ${dn}/$inadoc " >/tmp/x.sh
chmod 755 /tmp/x.sh
libreoffice --writer /tmp/${inadoc}.html.odt
#firefox /tmp/${bn}.html
clear
ls -l
#for each *.adocthe script will create a libreoffice file.Use landscape setting. Format->Page set radio button landscape.Enable markup management via EDIT-->Track Changes and click Record,Show,ManageEdit that file to identify changes or corrections.Once satisfied, save.If there is no one to review your edits, (I am proposing to do the review), pass the *.odt documentto a coordinator, He will reject each inappropriate individual change using the LOwriter options.The changes that remain (and the coordinator can add or modify them) get back to the author.The author now edits the correspondint adoc file, matches the changes in the Writer document tothe adoc file, and updates the adoc file.He then submits the *.adoc file as a PR.The following is an example of what a coordinator (repository owner) would look at for approval. If there are update refusals, the document goes back to the writer. The author can also concurrently provide the *.adoc to the editor. The two are returned to the author for him/her to issue the Pull request. The editor would also update the accompanying adoc file.Here is an example of an edit of "Desktop.adoc".And this is the corrected string after update to the *.adoc file.Prior to this update, the [package]*fontconfig* cache files were placed in the `/var/cache/fontconfig` directory. This location is not compatible with the `OStree` model used by Fedora Atomic, which prevented using the same package for Atomic and other Fedora variants. To fix this incompatibility, the cache files have been moved to `/usr/lib/fontconfig/cache`.If you want help with editing, and it is OK with Adam, Richard or others I will be glad to devote time to reviewing your postings prior to your issuing a PR. My location is in the CC aboveRegards
LeslieLeslie SatensteinMontréal Québec, Canada
On Wednesday, August 22, 2018, 12:58:00 p.m. EDT, Richard England <pdx.limey@xxxxxxxxx> wrote:Would it be possible to create a video of or for this lesson so it can be shared later?
I, too, am finding the editing process difficult to get into.
On 08/22/2018 04:48 AM, Adam Samalik wrote:
Hi Leslie,
I really value your work and I'd really like to help you to integrate it. But rather than doing the integration work myself (for which, to be fair, I don't have many spare cycles), I'd like to teach you how to do it yourself. The benefits would be:
* The integration of your work wouldn't generate additional work for other people, other than the actual review + feedback* You would be able to get feedback in the PR itself — there is a space for discussion, as well as posting inline comments* Many different people could help with commenting, reviewing, and even merging the changes* You would get credit as those changes would be clearly marked as yours
I'd rather spent an hour teaching you how to do future changes yourself, rather than doing it myself for 8.77 minutes. Especially with the amount of work you do, I wouldn't be able to keep up long-term. Also, there are many other people out there that could help to review the changes.
I know, git might be a new tool for many writers, and learning it might require some effort, but using it has many benefits for large communities such as Fedora, where we need to scale our work between many people living in different parts of the world and different timezones. If we want to work in a large community, or want to build a large community, we need to have workflows that scale. And git is one of the least horrible options there.
So, I'm happy to have a video call with you, even for an hour, going through the integration of your changes, so you feel comfortable doing them yourself next time. Would that work for you?
Please let me know.
regards,Adam
On Mon, Aug 20, 2018 at 5:43 PM Leslie S Satenstein <lsatenstein@xxxxxxxxx> wrote:
Hi Adam,
Your response will go a long way to understanding what I mean and do by "editing"
Can you help me out with integrating editing to the *.adocs?
What I have attached is one fairly short libreoffice writer document (1.5 pages) and the corresponding updated Desktop.adoc.
Before I can generate a pull request, I made a correction and asked some questions inside the libreoffice writer file. Those questions, if properly responded to, are to be the modifications to be made to the corresponding *.adoc file. A third x.sh file just invokes vim against the location to where the target adoc file resides.
I am and attaching a zip file with the updated Desktop.adoc and the corresponding libreoffice "Desktop.adoc.odt". The way I see things working, the libreoffice document is the working document. When it is clean, the contents therein are what is transfered to the corresponding *.adoc file and a PR sent.
2) Can you please note. Not all document writers are git users. They are writers, and can follow instructions. Please add a definition of a Pull Request.
Pull Request: A formal request document, transmitted to the owner of the git repository. The PR contains revisions or insertions that you are requesting for that git repository.
Regards
Leslie
Leslie SatensteinMontréal Québec, Canada
--
Adam Šamalík
---------------------------
Software Engineer
Red Hat
_______________________________________________ docs mailing list -- docs@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to docs-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/docs@xxxxxxxxxxxxxxxxxxxxxxx/message/MUZ6533QHMBY5SH6NPKGQUE6ZP4NCX72/
Adam Šamalík
---------------------------
Red Hat
_______________________________________________ docs mailing list -- docs@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to docs-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/docs@xxxxxxxxxxxxxxxxxxxxxxx/message/WXNLF62K625XM3FDMRKZCAGNCQAXBLKD/
