View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0005648 | Composr non-bundled addons | [All Projects] General / Uncategorised | public | 2024-03-26 01:38 | 2024-03-26 01:52 |
Reporter | Patrick Schmalstig | Assigned To | Patrick Schmalstig | ||
Severity | Feature-request | ||||
Status | assigned | Resolution | open | ||
Summary | 0005648: Implement points escrowing for issue tracker | ||||
Description | Consider 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 Information | Will 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? | ||||
Tags | Roadmap: Over the horizon | ||||
Time estimation (hours) | |||||
Sponsorship open | |||||
related to | 0005637 | closed | Patrick Schmalstig | composr_homesite_support_credits: Consider better or alternate Mantis integrations |
|
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. |
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 |