"Repair" Menu: Cancelling a Repair Operation in Progress, Shows a Potential Issue

[touwys]

Cancelling either one of the "Quick" or "Deep" Repair actions while they are in progress, may need attention. Clicking the "Cancel" button appears not to cancel the process properly — and apparently without ill effect. Difficult to describe exactly what happens. This needs verification.

[Borewit]

Need to repair the bike of my son first, priorities Touwys.

[touwys]

See #154 (comment)

[Borewit]

Is this issue still valid @touwys ?

[touwys]

@Borewit:

It has been well taken care of already.

Is there something I have perhaps overlooked, you think?

---

What worries me, somewhat, is that before we get too involved with resolving the next issues, we may want to review the consistency of the wording/nomenclature/terminology used throughout the application. That is so that the same phrases elicit the same activities across the board. I have touched upon this in #179. Should we not, perhaps, standardize on the baseline phrases first? To put this into perspective, also see:

Quote from #41

I find myself chasing windmills. I am quite uncertain at the moment about the way certain actions, when executed, are expected to behave. The nomenclature is confusing, to say the least. Underneath, there follows is a screenshot of one such example:

For instance: Are "Exact Matches Repair" (Ctrl + M) and "Find Exact Matches" one and the same thing — only they are accessible from two different locations? As they stand now, their actions do not match.

---

[Borewit]

we may want to review the consistency of the wording/nomenclature/terminology used throughout the application

Sure, but better to put such a lengthy comment directly in a new issue. We need to keep issues separated, only then we can address them in structured manner.

[touwys]

Sure, but better to put such a lengthy comment directly in a new issue. We need to keep issues separated, only then we can address them in structured manner.

Rather than posting this as a generalised issue, is it not best that we stay with, and log only specific instances, as an when they arise?

[Borewit]

In principal we can refine what we exactly are going to do in an issue. Good thing about that, that it contains the discussion what lead to it. It good to preserve and keep updating the first comment, as summary listing so that it clear what needs be done in a PR (implementation) requirements (resolve the issue).

[touwys]

In principal we can refine what we exactly are going to do in an issue. Good thing about that, that it contains the discussion what lead to it. It good to preserve and keep updating the first comment, as summary listing so that it clear what needs be done in a PR (implementation) requirements (resolve the issue).

Are you saying that we log inconsistency of terminology issues as and when they happen?

[Borewit]

Are you saying that we log inconsistency of terminology issues as and when they happen?

Sure, any request for change can be filed as an "issue". The word "issue" is that misleading, as an issue in the software is just one of the reasons one can raise a change request. If circumstances permit there is a preference to describe the desired situation after the change, in terms of what it should do, in favor of what it should not do.

Some articles I found related to writing Github issues:

• https://github.com/codeforamerica/howto/blob/master/Good-GitHub-Issues.md
• https://medium.com/nyc-planning-digital/writing-a-proper-github-issue-97427d62a20f