What to do with 4 documents in `docs` that do not belong to the website

[peterdesmet]

The /docs directory is where the chrono website is served from. It also contains 4 documents that do not seem to belong to the website, but that are "documents":

• Feature Report - ChronometricAge Extension.pdf
• Feature Report.md
• Implementation Experience Report- ChronometricAge Extension.pdf
• Implementation Experience Report.md

1. If these should be served from the website, it is better to place them in docs/assets/documents
2. If not, they maybe they can go in a /reports directory?

[tucotuco]

@baskaufs Suggestions? We don't have a precedent for these documents. We surely want them publicly available. We should also make sure they are at least linked to on the website. I think the documents would be very useful for other groups doing similar work to extend Darwin Core.

[baskaufs]

Alright, I've circled back to the VMS to see what it says. In Section 4.2.4, it says

If the proposed enhancement is adopted as part of the vocabulary standard, the user feedback reports should be archived as non-normative documents in the standard and links should be made from the document describing the enhancement to the user feedback reports.

I had actually forgotten that this said "...in the standard...". I actually think that is probably wrong and should be changed. I think including them in the standard elevates them to an inappropriate level. The important thing is that they be preserved and that people be able to find them by links from the authoritative standards documents.

The model here is the W3C. If you look at a W3C Recommendation like this, you'll see in the "Status of the document" section:

Please see the Working Group's implementation report.

That link leads you to the Implementation report, which is an archived W3C document, but which states clearly

This document is merely a W3C-internal document. It has no official standing of any kind and does not represent consensus of the W3C Membership.

I think we should follow this model and change the VMS accordingly. I'm not sure how we do that, since there isn't any sort of Maintenance Group for non-vocabulary standards. Maybe the TAG can do it.

If you look at the draft List of Terms document for the subjectPart controlled vocabularies, I've created a Section 1.3 in the introduction that links out to the Feature Report and Implementation Experience Report. I would just follow this model.

I never answered the actual question, which is "where should they go?" I like the /reports directory idea. I don't think they necessarily need to be part of the website. I think it's completely legitimate to just put them in a sensible place in the repo. The important thing is the link from the List of Terms to them.

[tucotuco]

@baskaufs That all sounds very good. I like the idea of the TAG making that recommendation about the VMS. Should it go for public commentary since the VMS is a standard?

@peterdesmet Let's go with the /reports directory. Are you willing to make those other changes Steve recommended while doing that? If you want me to, let me know and I will do it after the /reports directory is populated with those four docs.

[baskaufs]

Yeah, I think it could essentially be managed using the same process as vocabulary changes, but with the TAG standing in the place of the vocabulary Maintenance Group.

One of the problems with the VMS is that it's scope is restricted to vocabulary standards. That's because the charge of the task group that created it was restricted to that and not to standards in general. I think that the Process doc says something about the Interest Group that charters the Task Group taking responsibility for maintaining the standard after it's adopted, but at this point I don't even remember which group the Vocab TG was under. @tucotuco, do you remember? It may have been the TAG anyway. It would be useful to clear this up because other orphaned standards like the GUID AS are in the same situation. If the TAG continues to be a functioning group, maybe the TAG could just be given that responsibility.

[tucotuco]

No, I don't remember under which group that was spawned, but the TAG makes good sense in any case.

[ben-norton]

Those documents are critical for extension efforts. I think we should formalize a curated reports directory. The TAG could do the formalization part by providing guidelines regarding the contents of the reports directory.

[peterdesmet]

@tucotuco as this is unrelated to the website work, I'll let you make the necessary changes (including moving to /reports).

[tucotuco]

Accepted.

[tucotuco]

Done.