Add project closing #3602
Comments
|
Should teams whose applications have been denied be automatically removed at some point? Should teams whose applications are under review be marked as such after creation and before being approved? |
We've been leaving them up since they are indicative of the types of teams that are approved. We can probably keep doing that even after Decouple, since we will retain "brand fit" as a review criterion. |
I think the plan was to use this in closing teams? We can bring it back when we get to #3602, I guess.
I think the plan was to use this in closing teams? We can bring it back when we get to #3602, I guess.
|
Ok. Am I right that there are no team log-ins, only contributor/owner log ins? If so, can only the owner close a team? Do we want a way to transition team ownership to another member of the team? Which makes me wonder, can a team have more than one owner? |
Yes.
That's probably safest.
That would be good to have, but that's probably worth doing in another PR. It's possible to change ownership by request, it just needs to be done manually in the database.
Good question. What are the benefits to a team having more than one owner? Is it ability to edit the team? Should there be owners and also ~users who have team-editing privileges but not ability to close the team? |
|
@JessaWitzel Usually when I work on something like this I end up smashing around coding up a mess, just to wrap my head around the problem. Then I go back and produce several PRs methodically, starting from the inside out. In other words, the first PR probably modifies the database, the next one probably adds some Python APIs (and tests! and docs!). Then once there is Python API deployed, it's time for PRs that use the API and expose that functionality in the UI. In other words, it's good to plan out the work a bit. Also: we generally try to scope PRs to be about 100-400 line changes each (additions + deletions), for easier digestion. :-) Does that make any sense? |
I think the plan was to use this in closing teams? We can bring it back when we get to #3602, I guess.
I think the plan was to use this in closing teams? We can bring it back when we get to #3602, I guess.
I think the plan was to use this in closing teams? We can bring it back when we get to #3602, I guess.
|
Can we hide everything, as we do for closed ~user accounts? |
|
+1 from Freshdesk. As a workaround, I'm inclined to mark the project as "rejected" but leave a note in the description that it was by request. This will disallow receiving, which is what this +1 wants (not enough giving to cover administrative costs of receiving). |
No, because we don't allow ~user accounts to be closed unless they aren't project owners, which means we need to clear out the project in order to close ~user accounts. Closing ~user accounts seems to be the main driver ("user story"?) for people to want to close projects. |
|
Moving to a PR in #4287. |
|
Bug closing ~kytrinyx under #4286: https://sentry.io/gratipay/gratipay-com/issues/204048018/ |
|
You beat me to it. |
|
Bug fixed and #4286 resolved! Leaving open until we can notify the rest of the list in the project description ... |
|
@whit537, can you confirm we got some money back for https://gratipay.freshdesk.com/helpdesk/tickets/6453 before I close? There's no entry for it. |
|
Yeah, I don't see any money back yet. Ping again next Monday? |
|
Went ahead and pinged them just now. |
|
Gosh, what a mess! The way the PayPal fees worked out, the user in question still has a -$2.50 balance, and we don't allow closing accounts unless the balance is zero. 😩 |
Reticketed from #3601.
Notify
The text was updated successfully, but these errors were encountered: