View Issue Details

IDProjectCategoryView StatusLast Update
0005648Composr non-bundled addons[All Projects] General / Uncategorisedpublic2024-03-26 01:52
ReporterPatrick SchmalstigAssigned ToPatrick Schmalstig 
SeverityFeature-request 
Status assignedResolutionopen 
Summary0005648: Implement points escrowing for issue tracker
DescriptionConsider replacing sponsorship with the ability to escrow points on a particular issue on the tracker. This is a move towards decentralisation / the Bazaar model for Composr. With this system, points become a much more important and powerful rewards system / tool for members as they can use points to encourage development of features they want to see.

When points are escrowed onto a feature, the points are awarded to the person who develops the feature (the resolver).

If the issue gets closed (or deleted) instead of resolved, the escrowed points automatically enter resolved disputed status (full refund).

When a member escrows points on an issue, they are auto-monitored on that issue.

If a member escrows points but wishes to later retract them, they can "dispute" it like any other escrow. Consider whether or not we want disputed escrows for issues to be automatically and immediately resolved (full refund), or if we still want them to go through the standard process (someone with the privilege to resolve disputes has to review it).
Additional InformationWill require the points escrow system to accept content_type and content_id relations on records... and we will have a pseudo-resource for a Mantis tracker issue. Where a content_type and content_id is provided, recipient can be null, which means the submitter of the resource. In this case, the "submitter" would actually be the person who resolves the issue, not the one who submitted it, as we want the one who actually develops the issue to receive the points (the issue submitter would get the standard amount of "Tracker master" points). Keeping this in mind, it's possible there would be no submitter at present (since there is no resolver until the issue is resolved). In that case, the escrow is held in limbo / considered between the member and the content rather than another member.

Don't do anything else for content_type or content_id for now with escrows. But those could be used again in the future for other content types if someone wanted to develop other escrow integrations.

Need to consider cases where there might have been more than one developer involved on an issue. How do we handle those in escrows?
TagsRoadmap: Over the horizon
Time estimation (hours)
Sponsorship open

Relationships

related to 0005637 closedPatrick Schmalstig composr_homesite_support_credits: Consider better or alternate Mantis integrations 

Activities

Patrick Schmalstig

2024-03-26 01:46

administrator   ~0008445

Last edited: 2024-03-26 01:47

View 2 revisions

Consider if we also want to award a standard amount of points by default for resolved features. That way, even features developed which had no escrows on them are still awarded.

Perhaps this might be counter-intuitive to our end goal though. We want developers to focus on features other users want to see, not niche features only they want to see. Could easily encourage creep.

Issue History

Date Modified Username Field Change
2024-03-26 01:38 Patrick Schmalstig New Issue
2024-03-26 01:38 Patrick Schmalstig Status non-assigned => assigned
2024-03-26 01:38 Patrick Schmalstig Assigned To => Patrick Schmalstig
2024-03-26 01:38 Patrick Schmalstig Tag Attached: Roadmap: Over the horizon
2024-03-26 01:39 Patrick Schmalstig Relationship added related to 0005637
2024-03-26 01:46 Patrick Schmalstig Note Added: 0008445
2024-03-26 01:47 Patrick Schmalstig Note Edited: 0008445 View Revisions
2024-03-26 01:51 Patrick Schmalstig Description Updated View Revisions
2024-03-26 01:52 Patrick Schmalstig Additional Information Updated View Revisions