Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deleting projects #13

Open
stuartpb opened this issue Jan 21, 2018 · 2 comments
Open

Deleting projects #13

stuartpb opened this issue Jan 21, 2018 · 2 comments
Labels
model / schema Shortcomings of the project definition structure

Comments

@stuartpb
Copy link
Member

Deleting projects was, at one point, how I was thinking I would handle abandoning (#10) and possibly retiring (#7) or handing off (#8) projects - basically, keeping it so the repository only contains discrete projects I intend to to work on.

However, I'm taking the aforementioned issues (and the whole sphere around #1) into account, and thinking that my initial idea, that project files would, essentially, never be removed from the repo once added/merged (except under exceptional circumstances). might be more appropriate.

I think, to prevent fear of commitment, I may want to leave a policy of having some not-particularly-exceptional cases where I delete projects in place.

In some ways, it's easier to decide to delete projects after coming up with ways to keep them around than it is to do the reverse (as you don't have to hunting around for the last revision of various project files before they were deleted to restore them, and don't have to deal with data suddenly vanishing without a trace in projects tracking this dataset), and in some ways the reverse is true (as you don't need to worry about modeling all these cases coming out of #1, or potentially having to in the event that you encounter one of those scenarios that hasn't come up yet at the prospect of a new project's introduction to the dataset) - and in many ways, the worst thing to do is to mix both approaches (as it effectively inherits the problems of both approaches and none of the advantages afforded by making one call or the other).

For now, I'm going to commit to only deleting projects if I can't think of an issue to file or look to to determine how to resolve them (as I feel a lot of future-useful consideration is coming up in these issues right now, and that I can better handle data that, at worst, can be turned into some kind of featureless gravestone object in the event that I need to go full damnatio memoriae).

@stuartpb stuartpb added the model / schema Shortcomings of the project definition structure label Jan 21, 2018
This was referenced Jan 21, 2018
@stuartpb
Copy link
Member Author

One conflict that comes up for me in this, and one of the reasons I kind of did want to be free to delete ideas outright, is that a lot of the ideas I'm going to be looking at are other people's, and I don't want to crush feelings by going "Oh, sure, I'll add your idea to my list!", and then throwing it on the ground - if I have to phase an idea out, I'd rather things just revert to the way they were as if I'd never taken it on, instead of having to own up that I made a mistake in not initially rejecting the idea and playing with people's feelings.

@stuartpb
Copy link
Member Author

I think the pass and disregard fields being drafted in #10 do a good job of covering the two main scenarios where I'd be compelled to delete a project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
model / schema Shortcomings of the project definition structure
Projects
None yet
Development

No branches or pull requests

1 participant