Codify issue resolution process

[karl krughoff]

Phosim is used by several people and they are dutifully filling issues both here and a private issue tracker inside the LSST project. I have filed several of those and have found the resolution process unsatisfying. Specifically, new issues don't get any immediate feedback and largely the resolution practice is to close the issue as resolved with a mention of the version number.

There are two problems with this process in my experience: First, this gives no visibility into what is being worked on. A simple note in the issue saying "We will fix this in vX.X which will be out in X months" would go a long way because it would give enough information to the user to know how much effort to put into working around the problem.

The second is that I have found on occasion that the fix is not sufficient for my needs and the current process doesn't really have any way to iterate on the solution. It would be much more satisfying to me as a ticket filer to have an opportunity to test the fix myself to see if it really addresses my need before the issue is marked as resolved.

Just to get the ball rolling, the changes to the current process that I'd like to see are: 1. Some sort of prompt response as to the relative priority of particular tickets. 2. That the ticket not be closed until the issuer has a chance to say whether the proposed fix addresses their issue (this need not hold up releases or the normal workflow).

Other ideas for how to improve the process are welcome.

[karl krughoff]

While here checking on another issue I noticed that this has received no attention. I would like to urge that we have this conversation as this problem seems to be persisting.

As a concrete example issue #7 was filed in February. I think it was assumed that the new release would fix this as sometimes has happened in the past, but the bug is still present in v3.5, as reported in October. Unfortunately, there has still been no traffic on that ticket, and I know it's actually a pretty big issue for the folks dealing with that bug.

What's the best way to have this conversation?

[karl krughoff]

Just keeping things on the thread, from private email

issue #7 was filed after v3.5 was completed.

This is not technically true. Version 3.5 of phosim came out in April and #7 was first reported in February. I understand that it's hard to just keep including fixes as you are trying to put out a release, but there were 3 patch releases and none of them included a fix for #7. It would help to know why this was not prioritized while other bugs were. This is the main reason I'm suggesting codifying.

I understand that added process is added overhead, but from a user's perspective, it seems like overhead that's well worth it.

[karl krughoff]

@johnrpeterson I'm still interested in having this conversation, since it still seems to be an area that hangs people up when trying to use phosim. I'd be happy with a phonecon of interested parties, if this thread is too limiting.

I'd also be happy if the phosim team let us know what they expect the process to be. For me, it is just about communication and expectations. Interaction gets much easier if we know what to expect from the interaction.

[John Peterson]

We added just a new greeting message when you create a new issue that describes our policies and processes. We have interacted with many issues reporters about this in the past which guided our decisions on the v3.5.X patches, for example. (We explicitly asked reporters if the issue was critical to their current work or just for general information that they would like fixed in the future). But now the explicit policy statement now makes it clear that reporters should indicate this information in their general ticket.

[karl krughoff]

That's a great start! It is good that reporters can give you information, but how does information flow back the other way? Part of this request is to get some agreement from the phosim team to give feedback to reporters on how important the issue is from the phosim perspective.

[karl krughoff]

@johnrpeterson is there any advice on how issue filers should get feedback from the phosim team?

[John Peterson]

as always, please send me an email for more information about anything.

[karl krughoff]

@johnrpeterson The problem with this model is that people interested in the issue all will want to get the same information. It seems far more efficient to have communication related to the issues take place on the issue. Let me urge you to give as much information on the issue as you can.