Revision comments by/to all involved parties

[miggol]

When submitting a revision, applicants should be able to attach comments destined for the supervisor or committee.

Currently, applicants put messages to their supervisor in the general comments field, which sometimes ends up in a final approved proposal or confuses reviewers. This is undesirable.

When a proposal needs revision, the applicant is allowed to implement the reviewers' comments according to their own judgment and interpretation. Oftentimes, the changes they choose to make require clarification. This clarification sometimes goes through other channels (e-mail) or remains completely absent. Providing fields for:

1) Comments to the supervisor
2) Comments to the committee

would improve this situation.

Proposal:

The following is how I envisage the new process, based on a conversation with the secretary. I'm keeping implementation details (models/fields) to a minimum until we iron this out.

• The proposal form has an extra field for comments to the supervisor. This page also lists the supervisor conversation so far
• Each time the proposal is submitted to the supervisor, the applicant's text in this field is added to the supervisor conversation
• Each time the supervisor sends the proposal back to revision, their comments in the Decision form get added to the supervisor conversation
• When a proposal gets copied to make a revision, i.e. after FETC review, the supervisor conversation is cleared

It would be best to make the commenting process similar between the supervisor and committee conversations. I think this process is flexible enough to accommodate both, but some changes would have to be made for committee reviews:

• Reviewers now have two comments fields when making a decision: one for FETC eyes only, and one for the applicant
• Decide view lists decision comments from the previous review, and the applicant's reply
• Supervisor/applicant conversation is not visible to the committee
• When a proposal gets copied to make a revision, both conversations are cleared and the decision comments from the last committee review get added to the committee conversation

What are your thoughts, @tymees? More communication through the portal has been on the list for a while, and I think this proposal would be a reasonable start, even if it doesn't get us the do-it-all comment tree we can use everywhere right off the bat.

[tymees]

I'm keeping implementation details (models/fields) to a minimum until we iron this out.

Agreed, let's iron out the requirements first, then I'll bugger you about implementation ;)

• When a proposal gets copied to make a revision, i.e. after FETC review, the supervisor conversation is cleared

I don't think this is a good idea. I can see the 'WHY IS MY CONVERSATION GONE. WHY ARE THERE SO MANY BUGS' mails already, because users really don't understand that versions of a proposal aren't regarded as the same one. To be fair, from a human perspective that makes sense. The seperation only makes sense from our point of view.

Actually, reading ahead a bit, the problem becomes even worse. I'll reply in more detail further ahead.

It would be best to wise the commenting process similar between the supervisor and committee conversations. I think this process is flexible enough to accommodate both, but some changes would have to be made for committee reviews:

Small point: I would say that this conversation should also be available to the applicant, as not all supervisors are the best at passing on feedback in a timely manner. However, we should double check that with the secretary

• Reviewers now have two comments fields when making a decision: one for FETC eyes only, and one for the applicant

I would suggest that the 'FETC eyes only' field would be a different comments 'channel' as well

• Decide view lists decision comments from the previous review, and the applicant's reply
• When a proposal gets copied to make a revision, both conversations are cleared and the decision comments from the last committee review get added to the committee conversation

These two points are contradicting eachother, and the second point is also contradicting itself? How can you see/add something and clear it at the same time?

I don't think anyone really wants to clear anything, even if this was said verbatim. I think the actual requirement would be that all conversations are clearly contextualized. And with contextualized I mean it's clear when in the process a given comment was placed. For example, all comments are labelled with the refnum and maybe even with 'state change' comments added. (Kinda like how GitHub adds those 'xadded the enhancement label x hours ago' items between comments).

I might be wrong, but I have a hard time believing the clearing conversations is actually the desired behaviour.

Side point: point 1 also supports my previous comment about also adding applicants to the conversation

Proposal

As I made a lot of comments, let me type out how I see the desired functionality;

In order to move more of the conversation into the app, a total of three 'communication channels' or 'conversations' are needed:

1. applicant-superisor (if there is a supervisor)
2. applicant and supervisor-committee
3. committee internal

All conversations have these requirements in common:

• conversations are private between the participants of said conversation. (Ignoring god-mode-admins)
• a conversation spans the whole application process instead of the default of following a specific proposal
• The user interface clearly indicates the context of a comment
  • for example, the comments can be grouped under their version number, or labeled with said number
• If a proposal is copied as an independent, new, application the conversations are not copied over

Supervisor/applicant conversation

• The proposal form has an extra field for comments to the supervisor. This page also lists the supervisor conversation so far
• Each time the proposal is submitted to the supervisor, the applicant's text in this field is added to the supervisor conversation
• Each time the supervisor sends the proposal back to revision, their comments in the Decision form get added to the supervisor conversation
• The Decision form also lists the conversation so far

Conversation between supervisor/applicant and committee

• Decide view lists decision comments from the previous review, and any reply from the applicant
• In addition to a 'private' remark field on the decide page, a field for 'public' remarks is added
• Once a decision is finalized, the public remarks are added to this conversation

Internal committee conversation

• Once a decision is finalized, the private remarks (as described above) are added to this conversation

Further comments

• The committee decision page has two conversations to display. This is going to be a UX hell
• Adding to that, this entire thing might be an UX hell. Maybe we should call in Martijn
• I clearly don't know if UX should be preceded by 'an' or 'a'
• One might want to add state changes in all conversation (e.g. 'supervisor approved', 'FETC sent back for revision', 'User is an idiot and can't read'. Okay, maybe not that last one.)

[djhcapel]

• So Ty, you mean that reviewers (members of the FETC) can fill in a field that might be shared with applicants/supervisors and a field for internal communication only? That is how journal review processes are often implemented.
• Will the secretary be able to edit the fields for communication with applicants/supervisors? Sometimes, assessments are not in line with each other or are not entirely in line with the GDPR. I do not want applicants to see such comments.

[tymees]

So Ty, you mean that reviewers (members of the FETC) can fill in a field that might be shared with applicants/supervisors and a field for internal communication only? That is how journal review processes are often implemented.

Yes

Will the secretary be able to edit the fields for communication with applicants/supervisors? Sometimes, assessments are not in line with each other or are not entirely in line with the GDPR. I do not want applicants to see such comments.

Do you mean moderate the comments in the committee/applicants/supervisor 'conversation'? If that is a requirement, we could certainly add that. I do have some concerns about how to approach it though, as I worry about changing someone's words without their knowledge...

[djhcapel]

I will discuss the communication between members and applicants with the chairs of both chambers.

[djhcapel]

I discussed the communication-within-the-portal with the chairs last Tuesday. To make things 'worse': almost always, comments by members concern a particular document. Would it be feasible to have not only a comment field for the whole version of the application, and also comment fields per document? And each member can then indicate whether the content can be made available to the applicant? Or a field for the other members and one field which contents may be shared with the applicant? (At both levels: documents and application.)

The question then is how I communicate the chamber's comments to the applicant. What I do now is: a copy-paste áll comments into an email, then editing the text such that internal-only comments are deleted, duplications are deleted, comments about the same document are grouped, and comments are put in a logical order. That takes quite some time, though it makes it easier for the applicant to see what is actually required, and it makes it easier for the FEtC-H to check if comments have been taken into account after revision.

In the ideal world, I could tick those 'document-related' and 'overall-application-related' comments that are to be sent to the applicant (plus supervisor) and those comments are then combined in one field with comments for the applicant (and supervisor), with reference to the field these comments originate from (so that it looks like, e.g.:

• Application comment 1

• Information letter school management comment 1 comment 2

• Declaration of consent school management comment 1 comment 2 comment 3

• Information letter parents comment 1 comment 2

etc.

The 'rebuttal field' is then just one field in which the applicant can indicate how the comments have been dealt with, preferably repeating the comments so that reactions can be interspersed (in a different font, of with > before the original comments).

[miggol]

Clarification: Secretary should be able to send comments to applicants as well. Revision comments are bi-directional.