Categories should be defined very robustly with terms around discipline or delivery, that could not be twisted too easily. (e.g. Development, Research, Design, Marketing, Events …). There needs to be one category for all “offtopic/misc” items. The function of this “misc. category” would be creation of bottom-of-the-hierarchy listing. Ideally all the not so meaningful, vague, useless and outright scam projects should have a good chance of ending up at. From a voters perspective – misc items are always taken tertiary in regards of DCR projects needs. If anything worthwhile does end up there, it would have to really prove itself to be worth voting.

Categories are a good idea and I think they're in the pipeline already, the same kind of categories are required for the contractor management system so we should settle on a set that works for both use cases if possible.

With regard to a "Misc" type category where poor proposals would likely end up, I can see the appeal but I don't think that is desirable unless the voting rules are different for proposals in that category. If these "Misc" proposals have the same criteria for being approved then they need to have enough attention and informed votes.

I don’t propose to go this extreme with it, however find it worth considering to introduce some kind of indication of the projects result (successful, failed, cancelled) as well explore ways of incentivizing reporting (bonus pm costs?).

On reporting, that has been discussed before and I don't think there would be support to incentivize reporting. I do think we need a place to store progress/completion reports on Pi so that they can be associated with and found from the pages of successful proposals.

I like the idea of categories and it's a feature that could be implemented via frontend changes with minimal backend changes. You could have a categories drop down menu in the proposal editor that would be mandatory. The selected category would be inserted into the proposal markdown file before being sent to the politeiawww. The only backend changes that would be required would be to add some validation to politeiawww that checks and makes sure all submitted proposals have a category. This wouldn't be that difficult to implement.

Progress reporting is going to be a bigger challenge that will most likely require significant frontend and backend changes. This is something that we've had prior brainstorming discussions on, but nothing concrete ever emerged. Progress reporting is a feature that will be an integral part of Politeia and we'll probably be looking more into in the near future so any thoughts/ideas on the best way to tackle it would be welcome.

Good to hear, thought the categories would require more backend work. I’ll get it going in the design pipeline.

Re: Richardred: The voting rules would obviously be the same for all categories. How well they are defined is a visual communication nuance. My point being, for voters should root the awareness of “misc” being the tertiary item of importance for approval. E.g. first approve funding to the most useful and important items, then the less important ones – which is a quite natural approach.

I don’t also mean that all misc items shouldn’t get funded or openly dismissed as a category for crap. Real quality ones as contrast may actually end up having an easier time by being surrounded by low quality or useless.

#591 is a prior discussion on progress reporting.

Excuse me if i am intruding as i dont work on this project but here are some comments & suggestions.
I like the idea of categories and visibility it will bring to flow of money. This will certainly help stakeholders steer the project in a better way and balance spending according to goals of the project.

As for relegating Misc. category to bottom, why not let people up/downvote the proposals and allow sorting by votes, similar to reddit. We can put a paywall of say 0.5 DCR (rate is debatable) for this to discourage rigging and making people think before casting their vote. This way stakeholders can themselves decide what is junk instead of admins having one more task to do/lever of control. This might become much more manageable with LN, otherwise it might create too many on chain txs.

EDIT: I think jy-p is pretty much against any mandatory reporting and has said that he will be the first to leave if reporting becomes mandatory. So to get any reporting i think it has to be done by a third party like bee does by nagging everyone for details.

No worries, made the post for rooting discussion. I did consider the up- and downvoting also, but concluded it may give ground for another attack vector, thus exploring the other ways like flagging and moving proposals between categories. I think a soft censorship/nudging that may result a proposal being moved from one category to another is in some sense better than filtering by voting, as the motivation to engage in that kind of soft-nudging would firstly come if one obviously misrepresents its proposal. And if this is abused, it can also easily be proven.

Tradeoffs w/ up and downvoting:
For example, right now the sign-up for a user is 0.1 DCR, meaning at the current rate for roughly 850 dollars one can basically create 500 bots to push items up or down. This may be sold as a service or maintained as an on-going attack.

Secondly – browsing categories, proposals and reading through comments is an active engagement where one builds knowledge through interacting with the proposals. However if the proposals are already sorted by a kind of pre-vote sentiment (which can be manipulated by non-stakeholders), this can potentially backfire as lazier engagement as users are given an unproven sentiment based feed.

I’d be rather interested if any other interaction patterns could be developed that are better suited, as unlike centralised platforms we do have the feature of being censorship-proof, giving more playground in this topic.

Some thoughts from EETER regarding improving feedback.

When it comes to metrics, right now Pi only displays nr. of Votes and Percentages as each proposals counter. Occured to us that new users who have not formed a strong understanding around Votes being Tickets and Tickets having a timelocked value in DCR, can potentially educate them by functionally hinting this through the Pi UI.

For example, making it a statistical metric for each finished proposal, by in some way displaying how much “weight in DCR” was approximately used to vote for or against a proposal.
E.g. concept mockup:

Going deeper down the rabbithole, one can convert the apx. amount of DCR into USD, making an even stronger illustration of the data. I assume it be troublesome to attempt responsibly implement this in Pi, but I do see this being some humorous user project in lines of https://twitter.com/BigRekts ->

@linnutee I like the idea of showing the amount of DCR that is locked up. Implementing this would not be trivial though. I'd have to look into a bit more before being able to comment on the feasibility.

Regarding the twitter idea. I think it's a good idea, but would be outside of the scope of Pi. I believe that there are currently two different community run twitter accounts for Pi announcements. They may appreciate the idea. @RichardRed0x or @xaur would know more.

One issue that I've noticed with the current UI is that the quorum numbers have been a source of confusion. Do you have any thoughts on this?

I think its better to show % for quorum numbers and show vote numbers in tooltip on hover. Once quorum is achived, it should only show vote % with some indicator (simple text saying "Quorum Achieved"/ change of color to green) to show that quorum is already achieved.

before quorum: x% tooltip: y/x votes color: red
after quorum: x% (Quorum Achieved) tooltip: y/x votes color: green

Explaining quorum can be generalized to explaining participation of eligible tickets (which must break the quorum). And it should be, imo. For every proposal I'd like to see absolute numbers and % of how many tickets participated. 30k votes vs 10k votes are dramatically different outcomes.

Showing numbers would be an improvement, but a nice way to visualize it is appreciated ofc.

Regarding the twitter idea. I think it's a good idea, but would be outside of the scope of Pi. I believe that there are currently two different community run twitter accounts for Pi announcements. They may appreciate the idea.

Crunching historic data and mapping it to USD is a domain of dcrdata so also pinging @chappjc and @raedah for input.

Posting that on Twitter would be nice. Wait, isn't @PiApproveOrGTFO an existing account?

The latest design improves on displaying the quorum. Firstly this extending progress bar makes things a fair bit clearer. Don't think it's worth going as in-depth with explaining quorum as in voting.decred – if there's some quorum passed/colors/icons visible for each proposal, means it will be competing or worse case conflicting with the colors used to indicate the yes/no decision.

As sambiohazard mentioned, a tooltip copy explanation should be enough. If quorum does not pass, would be displayed in the status.

re: xaur – not a real account, only illustrating the idea. Indeed, as I mentioned this can be only naturally done as a community user project as that way it can live to its full potential w/o conflicting with actual Pi environment, just wouldn't be appropriate for many reasons. Only limit is creativity, I recon one can get pretty elaborate with it, e.g. communicate different levels of successes or fails with different memes/images/copy. As in this context, a 90%+ "no" is a pretty hard GTFO essentially as it takes 25 million USD to say this No. M-M-M-M-MONSTER KILL you know!

Understood, thanks. Love the idea of a brutal Twitter bot.

Re latest screenshot, I'd make the font black because all age/version/quorum/time left are important info. Also make "comments" lowercase.

Closing this issue due to inactivity or because it was included in the v1.0.0. If you feel this issue is still relevant, please re-open it to bring it to our attention.