Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Additional prose and documentation fixes for att.linguistic #1754

Closed
bansp opened this issue Mar 19, 2018 · 3 comments
Closed

Additional prose and documentation fixes for att.linguistic #1754

bansp opened this issue Mar 19, 2018 · 3 comments

Comments

@bansp
Copy link
Member

bansp commented Mar 19, 2018

This is to deliver on the promise given in ticket #1670, concerning the documentation of the freshly added class att.linguistic. I attempted to intervene inside chapter 14 only minimally and put most of the prose into a subsection (14.4.2). Modified the individual specs a bit as well.

The proposed changes can be inspected at LingSIG Jenkins pages:

@bansp
Copy link
Member Author

bansp commented Apr 9, 2018

Given that, as seen in the TEI-L today and as I know from off-list communication, these attributes are found by some to be quite a useful device, would it be outrageous to suggest that someone have a look at the proposed text to see if it contains many swearwords (or not) and/or if it appears to be on-topic, and then, that that person kindly merges the changes, to be reviewed in the context of the rest of the Guidelines, by the "end users"? :-)

And on a slightly more serious note, I would dearly like to avoid a situation whereby Peter becomes a victim of his kindness towards his LingSIG colleagues, and be forced into the role of a reviewer of a text that addresses something outside of his passion / immediate interests. I am now wondering if I should have just gone and merged the changes, and only post an informative issue about that, after the fact. Because it's just a follow-up on the previous ticket that we didn't write back then, when we didn't know whether the "word attributes" issue would be accepted by the Council and if so, to what extent.

Perhaps, Council dear, we can come to some operative conclusions for the future, like: "documentation that follows up on a previously accepted and implemented issue can be merged without a prolonged 'maturation' period, and thus without causing unnecessary grief and pull-request-maintenance issues"? Wouldn't that simplify things a bit? :-)

@peterstadler
Copy link
Member

Just read through it with great pleasure, many thanks @bansp

Just spotted two tiny typos which I'll fix in a subsequent commit.

@bansp
Copy link
Member Author

bansp commented Apr 17, 2018

Thank you very much, Peter!

@martinascholger martinascholger added this to the Guidelines 3.4.0 milestone Jul 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants