[chirp_devel] Issues

Dan Smith
Tue Jan 14 09:00:15 PST 2020


> I'd like to volunteer a little of my spare time to do some clean-up.
> 
> What's the policy here: not being the contributing party myself to that particular issue, can I just:
> * go and set duplicates to "Rejected"?

I'm not sure if this is what you mean, but: if you find a set of bugs that are the same issue, pick one that should be the main issue (either the earliest one, or the one with the most activity), add a "duplicates" link to the rest. Then I think you can close (just set the closed state) I think on the extras and it won't affect the main one.

But yes, you're welcome to chip away at that kind of stuff until your sanity runs out :)

> * mark issues as "Resolved" if nobody else did, but the feedback suggests that there is a solution?

Resolved isn't a terminal state, I don't think, which means it'll still be "open". If the thing is not a bug (i.e. they're complaining about something in their OS like driver issues) then it's "rejected" or it was not a bug (i.e. a usage issue). If it's fixed, then set to closed. Resolved is probably only useful as a transient state where you expect the people on the bug to confirm that it's fixed before you close.

> * go and make the header lines be more telling?

Sure.

> * go and close nonsensical requests, such as for non-existing radios (such as issue #5)?

Sure, although hopefully that one is a rarity.

> I just don't want to step on anyone's toes and abuse my freshly earned privileges.

Doesn't sound like that will be a problem. Unless you're promising things to people that we can't or won't do, you're not likely to step on my toes at least. I'll let you know if that happens :)

Thanks!

--Dan


More information about the chirp_devel mailing list