progit2 icon indicating copy to clipboard operation
progit2 copied to clipboard

Reduce redundancy in story description

Open udyzr opened this issue 5 years ago • 7 comments

Prior to this fix the description insinuates John had made two commits in this process phase. Please compare with elaborations shortly before first transcript for John's machine.

udyzr avatar May 10 '19 20:05 udyzr

The prose had just finished showing how Jessica makes changes, commits them, and pushes them (in painful detail). The line you're trying to change is where we switch back to John. We need to tell his part of the story quickly, and having just gone through all this detail with Jessica, we can shorthand it with John by just saying what he does.

But the change you're suggesting removes the fact that John makes changes at all, and it seems like that's important information. Can you explain a bit more why you think this change is necessary?

ben avatar May 11 '19 00:05 ben

But the change you're suggesting removes the fact that John makes changes at all, and it seems like that's important information. Can you explain a bit more why you think this change is necessary?

I am not sure this. With this phrase left in text as it is John edits then commits twice - I am not sure that is the intended scenario. Please compare with line 112 as stated in issue #1251. Both line 159 and 112 use present tense, so in my understanding John performs these two operations twice.

Kindly see also https://github.com/progit/progit2/issues/1249#issuecomment-484567185.

udyzr avatar May 12 '19 16:05 udyzr

Cit. The first developer, John, clones the repository, makes a change, and commits locally. (The protocol messages have been replaced with …​ in these examples to shorten them somewhat.) < here about what Jessica makes > Continuing with this example, shortly afterwards, John makes some changes, commits them to his local repository, and tries to push them....

udyzr avatar May 12 '19 16:05 udyzr

Let's also change line 128 to say something like this:

While John is busy making his changes, the second developer (Jessica) does the same thing -- clones the repository and commits a change:

Actually I am happy with book's every piece of text else I do not complain about. Change this type would rather form a side-effect for this issue "Reduce redundancy in story description". Kindly consider an issue for this change - shouldn't it need a good argumentation as every issue else - as well myself doen't share the need of change this kind? Furthermore I believe also in the end of the day it does not matter if Jessica and John are doing their changes parallel or subsequently in time.

udyzr avatar May 13 '19 20:05 udyzr

Change this type would rather form a side-effect for this issue "Reduce redundancy in story description".

I appreciate that you're trying to keep this PR focused, but I'm looking at the broader context of how we make this section more readable and useful. Your original suggestion is definitely a part of that, but I think we can do more, and this is the most on-topic place to do it.

Kindly consider an issue for this change - shouldn't it need a good argumentation as every issue else - as well myself doen't share the need of change this kind?

I don't think that every sentence needs a lengthy discussion. That's actually my role here, to make these quick decisions that probably no one has a strong opinion about. If you don't agree with this suggestion that's completely okay, I'm happy to accept your contribution the way you'd like it to look.

Furthermore I believe also in the end of the day it does not matter if Jessica and John are doing their changes parallel or subsequently in time.

For me it helps to visualize two people working on the code at the same time, and one of them pushes first. This doesn't matter on a technical level, but since this is in the part of the book where we're just introducing multi-person workflows, it helps to be as friendly as possible.

Well, however myself wonders why phrase ", shortly afterwards, John ... tries" was able to work before change in PR but it isn't with PR.

I actually think it doesn't work very well.

ben avatar May 14 '19 15:05 ben

Kindly ask person who sees the need for additional change as pointed to put it into repository. Myself either still didn't review text from this perspective or does not see the need for this adaption. I can raise PR for changes myself is convinced to be needed. Also if proposed additional change should receive some critics in future I am not ready to defend it cause I don't understand its need. I appreciate your understanding.

For me it helps to visualize two people working on the code at the same time

Even though. They two might have it (cloning, editing then committing) done literally at the same time or each after another one in very short time distance. This however does not matter. It is the order in which their's two pushes are made which matters imho. Should "While John is busy making his changes, the second developer" get some critics in future I am neither able nor ready to defend it. Please understand.

I actually think it doesn't work very well.

OK. To understand, to be convinced from as well as to follow I need background.

udyzr avatar May 14 '19 18:05 udyzr