Hi Peter,
I do recommend that tickets need to be checked upon and acted on when:
> A new minor/major version is released. If the ticket is also related to
> the newer version include this version into the ticket so people know it's
> still an issue for that version as well.
> The version
Hi David,
first off: thank you for voicing your opinion and starting this discussion.
Project governance decisions like this are often implicit or dictated by
tradition, so it's worth revisiting them occasionally!
On 19-09-26 16:42:25, David Vaz wrote:
>So if we would decide to close stalled
I agree with most stating that you can't just close tickets, but I do
recommend that tickets need to be checked upon and acted on when:
* A new minor/major version is released. If the ticket is also related
to the newer version include this version into the ticket so people
know it's
Hi David.
First off, well done for getting your first PR merged today!
Then, thanks for raising this; it's worth talking about at least.
I too would like to bring the ticket count down, but I would like to do it
by fixing them.
I think there are two approaches here. Certainly on DRF,
Hello,
I'm looking for someone to walk me through a fast path to getting active on
the community and start solving tickets!
I know there is a lot of docs, but it will be extra time of my working day,
so it will be very nice to be somehow mentored through delivering than
reading lots of docs!
I'm also strongly against closing an "idle" tickets. Sometimes tickets are
solved after many years (even 9, 10, or more). Age doesn't make them less
valid. In "open tickets scale" 4-5 years is not a long time. Closing
tickets just because they're old or because we would like to get a better
Interestingly there's an example of a long dead ticket rising 7-8 days ago:
https://code.djangoproject.com/ticket/14218
I believe this is an interesting reference for this conversation though not
sure if any side of the discussion is helped.
---
Elena Williams
Github: elena
>
> However, when generic foreign relations are created in a multi-db system
> using Django migrations, separate content-type tables are created for each
> db.
Does this not depend on the db_for_migrate and db_for_write methods of any
relevant database router?
I think only one database could
I'm also not sure of the value of closing stalled tickets. Closing them
makes them less visible, and as Claude says, they're still valid. Often I
find one that's been open years has "come up again" on the mailing list or
client work.
The fellows are the ones who work the most with ticketing
Sorry but I would *strongly* oppose any idea of closing a ticket because
noone commented in the last x years. Most of those tickets are still valid
issues, but they remain open because noone dedicated the appropriate time
to solve them, sometimes because the problem is a corner case, sometimes
I have seen other open source project handling that with a comment saying
the ticket will be closed in a short time. I assume closing with a comment
it's fine to reopen if it's still relevant would be fine. Maybe also
tagging the tickets with a label "closed as stalled" ?
On Fri, Sep 27, 2019,
11 matches
Mail list logo
