Closing of issues without opening new ones (and User Story process confusion)

Clearing the Path
1

I welcome the goal of working in an agile fashion, closing issues that aren’t getting us to nice clear path with clear next actions.

But I hate this new trend of just closing issues immediately when someone (mostly @chreekat ) finds them frustrating at all. It feels like negation of all the work that was going into something. There’s no proposal of what to do instead, it’s just a rejection.

I’m purposely wording this in a subjective way, I’m not saying what ought to be the case or how I ought to feel in some intellectual way. I’m just saying transparently, that I hate this, it feels awful to me.

https://git.snowdrift.coop/sd/snowdrift/issues/79

That started not ideally as the US-first approach since a mockup was already done. @iko did a bunch of work to create US’s which were then discussed and tweaked. They actually got consensus from @chreekat and @msiep . Everything was on track to actually having understanding and agreement.

Apparently, @mray did understand that he was expected to express his agreement or disagreement with the US’s and wanted the mockup to just stand for his view of everything. But it’s easy enough to clear up that misunderstanding and get his opinions on the written US’s.

As soon as all the US’s there have consensus (deleting or updating any that don’t already), then we would move on to evaluating how the mockup fits the US’s and getting consensus on the mockup, followed by implementation.

Everything was working fine enough on that issue.

Then @mray asked his question about the process which violates the newly-updated Code of Conduct rule:

Keep meta comments outside of focused topics

That was recently clarified, and it’s not @mray’s fault, the update wasn’t even announced clearly (I’ll do that right now). But then @chreekat went and responded with what I feel was throwing-his-hands-up and just closed a fine-enough-just-a-bit-big issue with no plan to do anything about it, which feels again, to me, like just a rejection and shut-down of everyone’s work. It seems even that @chreekat violated the CoC by reacting to @mray’s process question within the issue even though he knew about (prompted and proposed himself) the updated CoC.

I’m more convinced than ever about the value of the new CoC updates. Discussing meta concerns within issues effectively sabotages the issues themselves. None of us should ever do that again, and if we do, it’s those in-topic meta comments that be closed/deleted, not the whole issue.

This is not that unlike @chreekat’s unilateral code reset which was a very frustrating experience. Of course, he needs to have control over the code repo. But invalidating people’s work is really counterproductive. There needs to be no code-resets and issue-closings etc. without some clear plan about what happens next and how to move forward and not just throw away contributor’s work! And the fact that there’s some git history or closed-issues still exist is not enough to make this okay.

2

I support @chreekat in closing the issue. It is getting bigger and less understood by key contributors to the issue. This issue was getting way more counterproductive than putting a “closed” tag on it in my opinion.

3

I’m more concerned about the pattern of closing in general. I’m not opposed to closing, I’m opposed to closing without directly tying it to what to do next!

Anyway, that issue was not getting bigger and less understood, it was getting smaller and almost complete. Maybe we need a live chat to address this, but I think you and chreekat both just misunderstand at this point.

4

I’m more concerned about the pattern of opening. I see problems when It isn’t clear to all participants what the process of “closing” this issue means. Every attempt to make sense of it from a confused perspective is doomed to read a huge issue that IS getting bigger.

The problem is: we are posting too much and building too little.

1 Appreciation
5

I agree, and want to clarify that from here on all meta discussion about the process or about making sense of an issue or discussing closing it etc. needs to be on Discourse or IRC etc. It’s unworkable to let GitLab issues grow so big. They need to be restricted to just the actual item details.

Anyway, so here on Discourse we can discuss how to have better understanding of things like closing and what’s a positive, workable way to think about these things.

6

Since this thread started a while back, I feel some of the concerns have been at least mitigated by an improved process and understanding. I mostly still want some clarity about where to capture some not-now value for the (not all the time) cases where capturing seems worthwhile. With that clear, it will be easier to suggest doing that when closing unfinished issues.