pi: Add proposal author updates.

[lukebp]

This issue is for the Add proposal author updates item of the Pi Q3 2021 proposal.

Spec

Proposal authors need to be able to give periodic updates on the status of their proposal. These updates will be given as comments. The Politeia users will have the ability to interact with the author and ask further questions.

Currently, once a proposal vote has finished the proposal is locked and no additional comments can be made. The new behavior will be the following.

• Once a proposal vote has finished, all existing comment threads are locked.
• When a proposal author wants to give an update they will start a new comment thread. The author is the only user that will have the ability to start a new comment thread once the voting period has finished. Each update will have an author provided title.
• Anyone can reply to any comments in the thread and can cast upvotes/downvotes for any comments in the thread.
• The comment thread will remain open until either the author starts a new update thread or an admin marks the proposal as closed/completed.

politeiagui

• Each update will be shown as its own comment section. The updates will be displayed from newest to oldest.
• Each update will have a title.

Implemenation

const (
	// ProposalUpdateHint is the hint that is included in a comment's
	// ExtraDataHint field to indicate that the comment is an update
	// from the proposal author.
	ProposalUpdateHint = "proposalupdate"
)

// ProposalUpdateMetadata contains the metadata that is attached to a comment
// in the comment's ExtraData field to indicate that the comment is an update
// from the proposal author.
type ProposalUpdateMetadata struct {
	Title string `json:"title"`
}

• Add the ProposalUpdateMetadata and ProposalUpdateHint to the pi plugin API and politeiawww API.
• Add a UpdateTitleSupportedChars plugin setting. Limit this to just alpha numeric characters. This is more restrictive than proposal titles, but I would like to do it this way so that we leave the door open for more user friendly URLs in the future that reference the title.
• Add the plugin setting to the policy reply.
• Add validtion to the pi plugin comment hooks that implements the behavior described in the spec.
• Update the pictl commentnew command to be able to handle proposal updates.

[lukebp]

This is blocked by #1474. I want to get the billing metadata changes in first so that the proposal updates can key off of the billing status to know whether an author is allowed to give an update.

[xaur]

Great to see this! I see a few more points to consider.

Anyone can reply to any comments in the thread and can cast upvotes/downvotes for any comments in the thread.

I guess with the exception of voting on own comments that is no longer possible for normal comment threads.

The comment thread will remain open until either the author starts a new update thread or an admin marks the proposal as closed/completed.

This may be too restrictive. Imagine if a user wants to ask a question about update A after the author publishes update B. I think it is a possibility, esp. if the two updates talk about different features, and also considering that some stakeholders check only so often and could miss the discussion window.

I would suggest to keep all update threads open until the proposal is marked as closed/completed by the admin, and watch for abuse. If things get out of hand, then restrict further.

I want to get the billing metadata changes in first so that the proposal updates can key off of the billing status to know whether an author is allowed to give an update.

This ability should indeed end when the proposal is marked as closed/completed by the admin, to prevent abuse. May be worth adding to the original behavior list so it won't get missed.

[xaur]

These updates will be given as comments.

In terms of the data model, update looks like a different entity. Not only it has different access control rules (only author can post them, can be posted after the vote has finished), but also different structure (has title). When a new type surfaces I can imagine some edge cases:

• Can an Update be posted by the author before the vote has finished? "Feels like" a 80% No to me, but it may have a fun use case.
  • If we go with "No" for now, the UI must be smart about what form it shows to the author: regular comments (no title) before the vote has finished, and Update comments afterwards.
• Can an Update have no title?
• What are the restrictions for the title? I'd say same as the proposal title.
• What are the restrictions for the body? We may want to allow longer text here vs normal comments.
• Can an Update contain images (e.g. to show some exciting screenshot of the progress)? I guess not if they inherit most regular comment semantics. But should we consider such a feature? Why not.

[amass01]

will be working on that next

[lukebp]

I guess with the exception of voting on own comments that is no longer possible for normal comment threads.

Yes.

This may be too restrictive.

Start simple. We'll deal with it if it becomes a pain point.

May be worth adding to the original behavior list so it won't get missed.

It already is.

Can an Update be posted by the author before the vote has finished?

No. Start simple. We'll deal with it if it becomes a pain point.

Can an Update have no title?

No.

What are the restrictions for the title? I'd say same as the proposal title.

We're making it more restrictive. It will be limited to just alpha numeric characters to keep the door open to more user friendly URLs in the future.

What are the restrictions for the body?

Same as the normal comments for now. Start simple. We'll deal with it if it becomes a pain point.

Can an Update contain images (e.g. to show some exciting screenshot of the progress)?

No. Update comments have the same requirements as normal comments for now.

[lukebp]

This is also blocked by #1483.