Abandoning projects

[stuartpb]

One of the "further statuses" tied to #1

Also ties into #8 (as handoff can be considered a type of abandonment, and vice versa - abandonment an opportunity for handoff, in cases where someone else taking the project up could be sensible - which can happen even if I'm not expecting it)

[stuartpb]

Per #1, I think the first question here is whether abandonment should be considered as orthogonal to stage, or if it should supersede stage (ie. should abandonment be a stage).

I think there's a pretty clear case to be made for this being separate from stage, as I can "abandon" a project at any point.

I guess the next question is, what are the axes of abandonment? At what level is it substantially different to regard a project as having been abandoned one way versus another?

[stuartpb]

One idea is that I could have negative dex values to signal active disinterest in a project, and that projects with negative dex scores aren't "on the table" in various views.

[stuartpb]

One reason I'm hesitant to go the "negative dex score signals abandonment" route is that I'm not sure I want to enshrine dex as a part of the core project model (I think I'd rather have it be an ignorable axis on anything that isn't directly using it for sorting, as I want to potentially be able to phase it out altogether in favor of better sorting metrics in the future.)

[stuartpb]

One big class of abandonment I want to cover is "abandoned in favor of X instead"; right now, I'm thinking of doing that by just having the flag for abandonment or whatever be accompanied by remarks explaining why it was abandoned, but it might make sense to have, like, a more robust data structure that could maybe link to successor or successors (though "multiple successors" sounds like just a split: #11), or a link to the outside project it was abandoned in favor of.

Again, this feels more like a job for remarks.

[stuartpb]

Okay, I think this might be the distinction:

• Abandoned in favor of non-project alternative that makes the project irrelevant (alternative described in comments)
• Abandoned in favor of other projects
• Abandoned in favor of a mix of new projects and
• Abandoned out of disinterest or irrelevance that may one day come back (eg. no longer needing a pixel-reflashing app for Chromebooks)
• Abandoned out of disinterest or irrelevance that almost certainly isn't coming back (eg. a browser extension for a website that shut down)

Maybe this should be a string enum under a field name of down or downed? Maybe it should be a list of string tags? (That feels like it would be the best way of representing combinations of factors and circumstances.)

Maybe the field should be called disregard, with a list of tags representing reasons the idea has disregard from me.

[stuartpb]

Some ideas for disregard tags:

• redundant (this idea is redundant to what's already out there)
• merged (this idea was merged into another idea)
• split (this idea split into separate ideas)

Wait, what am I doing, this is a job for case-by-case bases, I shouldn't be getting ahead of myself with this (even if these are tags for ideas I looked at in the process of populating the dataset that's currently committed)

[stuartpb]

Like, I had more than one idea I'd tag as disregard: [unnecessary], with remarks explaining that what it wants to do is already pretty well doable.

[stuartpb]

One of the tags should definitely be retired, per #7.

[stuartpb]

Per what I just described about hurting feelings in #13 (comment), it might make more sense to frame this as pass than disregard...

no, actually, those should be two separate fields that have different semantics. pass means "this isn't for me, but if you think it's good, hey, go wild"; disregard means "this idea turned into something else, if you want to see what I've turned toward, check the remarks".

Sure, there are times where someone might want to pick up an idea that's downed as disregard, but hey, that's, as far as I'm concerned, them pursuing a new idea (yep, it's a question of quiddity again)

Short rubric: If the rationale for why I'm not pursuing the project is arguable, it's a pass: if it's straightforward (eg. "that website doesn't exist any more" - only the silliest people would argue "but you should still make the thing - what if it comes back?"), it's a disregard.

[stuartpb]

Also, disregard will probably have the other fields of the object (like stage and urls) cleared or ignored, while for pass projects those fields are still essentially valid.

[stuartpb]

There's also stuff like how pass can mean, like... I'm thinking I'll probably put a pass on Chatphrase (even though I've already done it), but if somebody comes up with a cool spin on it, I'll accept their work and publish it to chatphrase.com - basically, pass has further implications for stage <0 projects.

[stuartpb]

The intersection of dex and pass is interesting, as I can potentially have a high-dex project I've got a pass on, signalling that I think it's a cool idea, just not one I'm interested in pursuing (which is, um, an as-yet-unseen scenario, but one that's not, theoretically, out of the question).