CLDR-17566 Converting development process to markdown #3712
Conversation
|
|
||
| 3. If user does not select the Component, it remains for the group TC triage with Component=to-assess, Owner=anybody. These tickets will be assessed after all the pre-assessed tickets have been triaged. | ||
|
|
||
| 2. All TC members, look at [To-assess by Owner / Component](https://www.google.com/url?q=https%3A%2F%2Funicode.org%2Fcldr%2Ftrac%2Freport%2F100&sa=D&sntz=1&usg=AOvVaw3RRcS9UWwOlotoRAFsV3fJ) before each triage day. |
There was a problem hiding this comment.
You need to resolve links that start with https://www.google.com/url?q= first.
Easiest way is to paste into a browser's address bar; the browser will resolve it — in this case, to:
https://cldr.unicode.org/index/bug-reports#TOC-Filing-a-Ticket
| ### Filing tickets | ||
|
|
||
| 1. You can add set other fields, but don't change the Owner. That way the committee sees the incoming tickets (those marked as Owner: somebody). | ||
|
|
There was a problem hiding this comment.
There are extra blank lines between list items; these should be removed.
There was a problem hiding this comment.
Also, in the Summary, add a link to the comparison between the old (in plaintext) and the new (in plaintext).
|
|
||
| 1. The future folder tickets are moved to the discuss folder | ||
|
|
||
| 2. Unscheduled tickets (with no release number) are re-evaluated. |
There was a problem hiding this comment.
| 2. Unscheduled tickets (with no release number) are re-evaluated. | |
| 2. Unscheduled tickets (with no release number) are re-evaluated. |
wrong indentation for list
|
|
||
| 1. All reviewers should be done well before the end of the release, so that any problems can be taken care of. | ||
|
|
||
| 2. At release time, all the tickets with status "fixed" are changed to "closed". |
There was a problem hiding this comment.
| 2. At release time, all the tickets with status "fixed" are changed to "closed". | |
| 2. At release time, all the tickets with status "fixed" are changed to "closed". |
check indentation so it lines up
|
|
||
| ### Survey Tool in Production Phase! | ||
|
|
||
| 1. **Before** you make a commit, add a line to the Issues spreadsheet below ([Spreadsheet View](https://docs.google.com/spreadsheet/ccc?key=0AqRLrRqNEKv-dF9DdVRPVmhHdzhheDliOEpLSUhObXc#gid=3)), with status OPEN, bug number, short desc. |
There was a problem hiding this comment.
@macchiati Higher level comment: this is actually an obsolete process.
There was a problem hiding this comment.
Right. We just want to get the source into markdown before fixing.
|
|
||
| 1. Assignees periodically review and take care of their tickets. | ||
|
|
||
| 1. Go to [http://unicode.org/cldr/trac/report/61](http://www.google.com/url?q=http%3A%2F%2Funicode.org%2Fcldr%2Ftrac%2Freport%2F61&sa=D&sntz=1&usg=AOvVaw0UYmG2ygYOMySNUAGnbPKu) for **My Tickets** |
| 1. All commits must have as their first line: "CLDR-XXX <description>", where XXX is the ticket number. | ||
|
|
||
|
|
||
| 2. **Don't mark the bug as fixed! Instead,** |
|
|
||
| ### DTD Changes | ||
|
|
||
| * **If you are making any DTD changes, please follow the instructions on** [**Updating DTDs**](/development/updating-dtds)**.** |
There was a problem hiding this comment.
| * **If you are making any DTD changes, please follow the instructions on** [**Updating DTDs**](/development/updating-dtds)**.** | |
| * **If you are making any DTD changes, please follow the instructions on** [**Updating DTDs**](https://cldr.unicode.org/development/updating-dtds)**.** |
site-relative link (and there are others) but perhaps it's better to just make them absolute to start and then we can fix up en masse later?
|
The conversion is generally good but a lot of the content is out of date. Getting it moved over, though is a good step towards improvement. |
| --- | ||
| title: Handling Tickets (bugs/enhancements) | ||
| --- |
There was a problem hiding this comment.
Just a note: If this shows up in the output (I don't think it will) I can fix the conversion process. Don't remove it if you happen to see this show up oddly in the output.
|
Just to be clear, Chris's goal is to make sure that the text and formatting
are the same as the original, correcting the formatting where sites has
messed it up.
So he should not be trying to make any fixes to the text. That is for us to
do later.
…On Mon, May 13, 2024, 07:16 Steven R. Loomis ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In docs/site/development/development-process.md
<#3712 (comment)>:
> +---
+title: Handling Tickets (bugs/enhancements)
+---
If this shows up in the output (I don't think it will) I can fix the
conversion process.
—
Reply to this email directly, view it on GitHub
<#3712 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACJLEMBRROGDFVM6BHT22ITZCDDL3AVCNFSM6AAAAABHSD6Q42VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDANJSHAZTQNRZGE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I believe this resolves the changes you guys were talking about. @macchiati, I am a bit confused as to what I should put for the diffs between the plain texts. I tried your suggestion with Google Docs history but it doesn't ignore whitespace so I couldn't get it to work and was just using a browser tool. Let me know what I should link to. |
|
Hmmm.
We'd like to give the reviewer confidence that the plaintext is preserved.
One idea would be to normalize the spaces in both eg:
[ \t]+ => space
[ \t]\n[ \t] => \n
Alternatively, we could make a side PR, checking in the original plaintext
in one commit, and the generated plaintext in a second. Then people can use
the github diff (which can ignore whitespace).
Any other ideas?
…On Wed, May 22, 2024 at 4:18 PM Chris Pyle ***@***.***> wrote:
I believe this resolves the changes you guys were talking about.
@macchiati <https://github.com/macchiati>, I am a bit confused as to what
I should put for the diffs between the plain texts. I tried your suggestion
with Google Docs history but it doesn't ignore whitespace so I couldn't get
it to work and was just using a browser tool. Let me know what I should
link to.
—
Reply to this email directly, view it on GitHub
<#3712 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACJLEMFO4OUZZF4THRSC4ITZDURTTAVCNFSM6AAAAABHSD6Q42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRVHEZTCNZWGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I looked into it some more and it seems like the history on google docs just looks at what the user did not the differences, so even if you copy in the same text the history looks like deleting and re-entering. Another option would be to include a screenshot of my diff tool in the comment. This might not be as convincing as a PR but would be faster. |
|
A screen shot would work, good idea.
…On Wed, May 22, 2024 at 4:44 PM Chris Pyle ***@***.***> wrote:
I looked into it some more and it seems like the history on google docs
just looks at what the user did not the differences, so even if you copy in
the same text the history looks like deleting and re-entering. Another
option would be to include a screenshot of my diff tool in the comment.
This might not be as convincing as a PR but would be faster.
—
Reply to this email directly, view it on GitHub
<#3712 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACJLEMDPBFQJ3KT7M6XNLSTZDUUVLAVCNFSM6AAAAABHSD6Q42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRVHE2TEMBUHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
CLDR-17566
Part of the CLDR --> GFM conversion project
View text diffs here
ALLOW_MANY_COMMITS=true