Re: feature request: add iso_week_day to querysets, analogous to iso_year

[Adam Johnson]

Right, my bad.

So itt looks  like we h ave week_day which has sunday = 1, while ISO week
days have monday = 1. What other "peculiar and unintuitive" behaviour is
there Anatol?

On Wed, 25 Sep 2019 at 15:39, Mariusz Felisiak 
wrote:

> In this ticket we mentioned *iso_week* not *iso_week_day*. *week *lookup
> returns the week number (1-52 or 53) according
> to ISO-8601 (https://en.wikipedia.org/wiki/ISO-8601), that's why *iso_week
> *is not necessary.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/696d7546-55c0-4e6a-a81a-d0b75aa347ee%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM04H7K_x%2BuKV%2BHrHY6cVGtEwKtm%2B5ONH2QoZtyeRHBqKA%40mail.gmail.com.

Re: feature request: add iso_week_day to querysets, analogous to iso_year

[Anatol Ulrich]

On Thu, Sep 26, 2019 at 11:33 AM Adam Johnson  wrote:

> Right, my bad.
>
> So itt looks  like we h ave week_day which has sunday = 1, while ISO week
> days have monday = 1. What other "peculiar and unintuitive" behaviour is
> there Anatol?
>

it's just that. Django's docs say it themselves (emphasis mine):


> The week_day lookup_type is calculated *differently from most databases
> and from Python’s standard functions*. This function will return 1 for
> Sunday, 2 for Monday, through 7 for Saturday.
>

Cheers
Anatol

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEeS38t%2BN%3D0sGDyV2-d9YqwtG0CgRae%2B%3D%2BBvpP0qFch10NrV9A%40mail.gmail.com.

Re: The floatformat filter sometimes returns "-0" rather than "0"

[Adam Johnson]

I think you can reopen the ticket and make a pull request!

On Thu, 26 Sep 2019 at 00:55, Sky Christensen 
wrote:

> It seems that so far two people have replied in favour of re-opening
> this ticket (or maybe make that three people if you count me), and none
> have replied against re-opening it.
>
> It's been two weeks since the last reply.
>
> What's the next step now?
>
>
> On 2019-09-12 21:52, Adam Johnson wrote:
> > +1 to swapping -0 for 0
> >
> > On Thu, 12 Sep 2019 at 12:44, Kye Russell  wrote:
> >
> >> Sounds reasonable. As you said, the template tags (well, this one)
> >> seem to be to prepare things for human consumption, not to expose
> >> computer science intricacies.
> >>
> >> If I saw this presented on a website, as a ‘developer-user’,
> >> I’d probably consider it a bug. I’m unsure of other uses of this
> >> filter though.
> >>
> >> Kye Russell
> >> Sent from my iPhone
> >>
> >>> On 12 Sep 2019, at 12:54 pm, Sky Christensen
> >>  wrote:
> >>>
> >>> Hi,
> >>>
> >>> I'd like to discuss reopening this wontfix'ed ticket:
> >> https://code.djangoproject.com/ticket/30761
> >>>
> >>> The issue is that for values between 0 and -0.5, the floatformat
> >> filter returns "-0", whereas I think that most people would expect
> >> it to return "0".
> >>>
> >>> The ticket was wontfix'ed because "this behavior is consistent
> >> with builtin round() and -0 exists in floating-point arithmetic".
> >>>
> >>> Can I propose that in this case the better way to decide the
> >> result that it should produce is to ask what an ordinary person
> >> would expect to see, rather than what's consistent with a particular
> >> Python function?
> >>>
> >>> When humans round -0.3 to the nearest whole number, we express the
> >> result as 0, not -0. Given that the point of template tags and
> >> filters is to make data more human-readable, I think returning "0"
> >> is preferable in this case than returning "-0".
> >>>
> >>> If this ticket is reopened, I'll be happy to submit a patch for
> >> it.
> >>>
> >>> Cheers,
> >>>
> >>> Sky
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> >> Groups "Django developers  (Contributions to Django itself)" group.
> >>> To unsubscribe from this group and stop receiving emails from it,
> >> send an email to django-developers+unsubscr...@googlegroups.com.
> >>> To view this discussion on the web visit
> >>
> >
> https://groups.google.com/d/msgid/django-developers/aec9450abcb511a0bb4a020c770a0483%40skychristensen.com
> .
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Django developers  (Contributions to Django itself)" group.
> >> To unsubscribe from this group and stop receiving emails from it,
> >> send an email to django-developers+unsubscr...@googlegroups.com.
> >> To view this discussion on the web visit
> >>
> >
> https://groups.google.com/d/msgid/django-developers/1F8DEBF9-FBEB-4A1C-BE3B-CA9D4507E702%40kye.id.au
> .
> >
> > --
> > Adam
> >
> >  --
> > You received this message because you are subscribed to the Google
> > Groups "Django developers (Contributions to Django itself)" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> > an email to django-developers+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/django-developers/CAMyDDM3FhTEUmWmpHaAqHuRxCbqHJcH6riS9vQ%2BNjhx3LcGhPA%40mail.gmail.com
> > [1].
> >
> >
> > Links:
> > --
> > [1]
> >
> https://groups.google.com/d/msgid/django-developers/CAMyDDM3FhTEUmWmpHaAqHuRxCbqHJcH6riS9vQ%2BNjhx3LcGhPA%40mail.gmail.com?utm_medium=email&utm_source=footer
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/f11994750333b35688ad5f8053e1f13f%40skychristensen.com
> .
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2jQXp3FDjmiHzYoxWM069%3D6royttHd6Av8a4GUT%3DpYmA%40mail.gmail.com.

Re: feature request: add iso_week_day to querysets, analogous to iso_year

[Anatol Ulrich]

one last thing preventing me from submitting the PR is that the
implementation is database specific and while I'm reasonably sure my oracle
implementation is correct, I don't have an easy means of testing it. What's
the team's go-to approach here?

Cheers
Anatol

On Wed, Sep 25, 2019 at 2:10 PM Anatol Ulrich 
wrote:

> Hello!
> As the subject states I'd like to see iso_week_day in the queryset API (in
> fact, I have already implemented it in my local django fork...), for
> consistency reasons (iso_year already exists), and because the way week_day
> works is quite peculiar and unintuitive.
>
> Cheers
> Anatol
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/pLS-eKhJBwE/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/3ac26305-1411-4547-b22d-753d5ce6cec0%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEeS38vrBk5gt5WvpJwEomx-jkU_RggVNFc4QoWA%2BFEQ%2BF79Wg%40mail.gmail.com.

Re: feature request: add iso_week_day to querysets, analogous to iso_year

[Anatol Ulrich]

nevermind, found official dockerfiles for XE, will try those

On Thu, Sep 26, 2019 at 12:58 PM Anatol Ulrich 
wrote:

> one last thing preventing me from submitting the PR is that the
> implementation is database specific and while I'm reasonably sure my oracle
> implementation is correct, I don't have an easy means of testing it. What's
> the team's go-to approach here?
>
> Cheers
> Anatol
>
> On Wed, Sep 25, 2019 at 2:10 PM Anatol Ulrich 
> wrote:
>
>> Hello!
>> As the subject states I'd like to see iso_week_day in the queryset API
>> (in fact, I have already implemented it in my local django fork...), for
>> consistency reasons (iso_year already exists), and because the way week_day
>> works is quite peculiar and unintuitive.
>>
>> Cheers
>> Anatol
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/pLS-eKhJBwE/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/3ac26305-1411-4547-b22d-753d5ce6cec0%40googlegroups.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEeS38s9zhbGv91QGOcHN993ytXHOOiYjynAOVM1rex3dKPt%2BQ%40mail.gmail.com.

Feature idea: bulk_associate: Add ManyToMany relationships in bulk

[David Foster]

Given the following example model:

class M1(models.Model):
m2_set = models.ManyToManyField('M2')

It is already possible to associate *one* M1 with *many* M2s with a single 
DB query:

m1.m2_set.add(*m2s)

However it's more difficult to associate *many* M1s with *many* M2s, 
particularly if you want to skip associations that already exist.

# NOTE: Does NOT skip associations that already exist!
m1_and_m2_id_tuples = [(m1_id, m2_id), ...]
M1_M2 = M1.m2_set.through
M1_M2.objects.bulk_create([
M1_M2(m1_id=m1_id, m2_id=m2_id)
for (m1_id, m2_id) in
m1_and_m2_id_tuples
])

What if we could do something like the following instead:

bulk_associate(M1.m2_set, [(m1, m2), ...])
# --- OR ---
bulk_associate_ids(M1.m2_set, [(m1_id, m2_id), ...])

I propose to write and add a *bulk_associate()* method to Django. I also 
propose to add a paired *bulk_disassociate()* method.

*1. Does this sound like a good idea in general?*


In more detail, I propose adding the specific APIs, importable from 
*django.db*:

M1 = TypeVar('M1', bound=Model)  # M1 extends Model
M2 = TypeVar('M2', bound=Model)  # M2 extends Model

def bulk_associate(
M1_m2_set: ManyToManyDescriptor,
m1_m2_tuples: 'List[Tuple[M1, M2]]',
*, assert_no_collisions: bool=True) -> None:
"""
Creates many (M1, M2) associations with O(1) database queries.

If any requested associations already exist, then they will be left 
alone.

If you assert that none of the requested associations already exist,
you can pass assert_no_collisions=True to save 1 database query.
"""
pass

def bulk_associate_ids(
M1_m2_set: ManyToManyDescriptor,
m1_m2_id_tuples: 'List[Tuple[Any, Any]]',
*, assert_no_collisions: bool=True) -> None:
pass

If assert_no_collisions is False then (1 filter) query and (1 bulk_create) 
query will be performed.
If assert_no_collisions is True then only (1 bulk_create) will be performed.

def bulk_disassociate(
M1_m2_set: ManyToManyDescriptor,
m1_m2_tuples: 'List[Tuple[M1, M2]]') -> None:
"""
Deletes many (M1, M2) associations with O(1) database queries.
"""
pass

def bulk_disassociate_ids(
M1_m2_set: ManyToManyDescriptor,
m1_m2_id_tuples: 'List[Tuple[Any, Any]]') -> None:
pass

The database connection corresponding to the M1_M2 through-table will be 
used.

*2. Any comments on the specific API or capabilities?*


If this sounds good I'd be happy to open an item on Trac and submit a PR.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3ca80bdc-8bc9-4304-8723-6e23302e1364%40googlegroups.com.

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

[David Foster]

Errata: The proposed default value for assert_no_collisions is False rather 
than True, for safety.

On Thursday, September 26, 2019 at 10:45:45 AM UTC-7, David Foster wrote:
>
> Given the following example model:
>
> class M1(models.Model):
> m2_set = models.ManyToManyField('M2')
>
> It is already possible to associate *one* M1 with *many* M2s with a 
> single DB query:
>
> m1.m2_set.add(*m2s)
>
> However it's more difficult to associate *many* M1s with *many* M2s, 
> particularly if you want to skip associations that already exist.
>
> # NOTE: Does NOT skip associations that already exist!
> m1_and_m2_id_tuples = [(m1_id, m2_id), ...]
> M1_M2 = M1.m2_set.through
> M1_M2.objects.bulk_create([
> M1_M2(m1_id=m1_id, m2_id=m2_id)
> for (m1_id, m2_id) in
> m1_and_m2_id_tuples
> ])
>
> What if we could do something like the following instead:
>
> bulk_associate(M1.m2_set, [(m1, m2), ...])
> # --- OR ---
> bulk_associate_ids(M1.m2_set, [(m1_id, m2_id), ...])
>
> I propose to write and add a *bulk_associate()* method to Django. I also 
> propose to add a paired *bulk_disassociate()* method.
>
> *1. Does this sound like a good idea in general?*
>
>
> In more detail, I propose adding the specific APIs, importable from 
> *django.db*:
>
> M1 = TypeVar('M1', bound=Model)  # M1 extends Model
> M2 = TypeVar('M2', bound=Model)  # M2 extends Model
>
> def bulk_associate(
> M1_m2_set: ManyToManyDescriptor,
> m1_m2_tuples: 'List[Tuple[M1, M2]]',
> *, assert_no_collisions: bool=True) -> None:
> """
> Creates many (M1, M2) associations with O(1) database queries.
> 
> If any requested associations already exist, then they will be left 
> alone.
> 
> If you assert that none of the requested associations already exist,
> you can pass assert_no_collisions=True to save 1 database query.
> """
> pass
>
> def bulk_associate_ids(
> M1_m2_set: ManyToManyDescriptor,
> m1_m2_id_tuples: 'List[Tuple[Any, Any]]',
> *, assert_no_collisions: bool=True) -> None:
> pass
>
> If assert_no_collisions is False then (1 filter) query and (1 bulk_create) 
> query will be performed.
> If assert_no_collisions is True then only (1 bulk_create) will be 
> performed.
>
> def bulk_disassociate(
> M1_m2_set: ManyToManyDescriptor,
> m1_m2_tuples: 'List[Tuple[M1, M2]]') -> None:
> """
> Deletes many (M1, M2) associations with O(1) database queries.
> """
> pass
>
> def bulk_disassociate_ids(
> M1_m2_set: ManyToManyDescriptor,
> m1_m2_id_tuples: 'List[Tuple[Any, Any]]') -> None:
> pass
>
> The database connection corresponding to the M1_M2 through-table will be 
> used.
>
> *2. Any comments on the specific API or capabilities?*
>
>
> If this sounds good I'd be happy to open an item on Trac and submit a PR.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/74c15393-9312-48bc-ac06-a3d4360b3432%40googlegroups.com.

Question about ticket #15610: Generic Foreign Keys break when used with multi-db

[Yasunari Kato]

Hello all,

I was looking into ticket 15610 (https://code.djangoproject.com/ticket/15610), 
which describes an issue where generic foreign keys fail when the 
content-type table is located in a separate database from the tables 
containing the generic relations.

The ticket makes this assumption "There can only be one valid and 
consistent content-type table in a system. In a two-db system, the content 
type table will be in either db A or db B. Therefore, a portion of the 
system's tables will be registered in a content-type table that is stored 
in a different database."

However, when generic foreign relations are created in a multi-db system 
using Django migrations, separate content-type tables are created for each 
db.

I was wondering if this was the desired behavior, and if that’s the case, 
if this ticket is still relevant?

Thank you,

Yasunari Kato

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d59be6ca-f73d-496b-a44a-fd625eeaf9b3%40googlegroups.com.

Stalled tickets

[David Vaz]

Hi,

I am playing around at the DjangoCon US 2019 Sprints and while trying to do 
my share one thing stands out in the open tickets is: Some are very old and 
others have not been touched in a while. 

I did a simple analysis of accepted and open tickets based on last modified 
time (kind of a live status).

The numbers might change over time, but I also linked them: 

Modified at any time All 
:
 
1264

Modified in last 5 years 
:
 
1039

Modified in last 4 years: 

  
887

Modified in last 3 years 
:
  
728

Modified in last 2 years 
:
  
494

Modified in last year 
:
  
   329


So if we would decide to close stalled tickets after some inactivity period 
we could massively reduce the opened tickets list. Imagine if we close any 
ticket no modified in the last 5 years we would reduce by 20% the active 
ticket list. If we decide to be more aggressive, say 3 years we can cut by 
half the active tickets list. 


I also believe that apparently stalled tickets might be important. This 
auto-close approach would also trigger *a live prof, *any automatically 
closed ticket could be reopened if relevant.


Let us focus the efforts on the really active ones.


Anyway, these are just my thoughts. 


For those of you who do not know me, I am organizing DjangoCon Europe 2020 
in Porto Portugal and you are all invited, official details are about to be 
released.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b3b855e5-7fd6-4b26-b365-75ff687c4b4c%40googlegroups.com.

Re: The floatformat filter sometimes returns "-0" rather than "0"

[Sky Christensen]

Thanks Adam. I wasn't sure if I needed to wait for a core developer to 
re-open the ticket.


I just re-opened it then and I'll get onto writing a patch soon.


On 2019-09-26 20:58, Adam Johnson wrote:

I think you can reopen the ticket and make a pull request!

On Thu, 26 Sep 2019 at 00:55, Sky Christensen 
wrote:


It seems that so far two people have replied in favour of re-opening

this ticket (or maybe make that three people if you count me), and
none
have replied against re-opening it.

It's been two weeks since the last reply.

What's the next step now?

On 2019-09-12 21:52, Adam Johnson wrote:

+1 to swapping -0 for 0

On Thu, 12 Sep 2019 at 12:44, Kye Russell  wrote:


Sounds reasonable. As you said, the template tags (well, this

one)

seem to be to prepare things for human consumption, not to expose
computer science intricacies.

If I saw this presented on a website, as a ‘developer-user’,
I’d probably consider it a bug. I’m unsure of other uses of

this

filter though.

Kye Russell
Sent from my iPhone


On 12 Sep 2019, at 12:54 pm, Sky Christensen

 wrote:


Hi,

I'd like to discuss reopening this wontfix'ed ticket:

https://code.djangoproject.com/ticket/30761


The issue is that for values between 0 and -0.5, the floatformat

filter returns "-0", whereas I think that most people would

expect

it to return "0".


The ticket was wontfix'ed because "this behavior is consistent

with builtin round() and -0 exists in floating-point arithmetic".


Can I propose that in this case the better way to decide the

result that it should produce is to ask what an ordinary person
would expect to see, rather than what's consistent with a

particular

Python function?


When humans round -0.3 to the nearest whole number, we express

the

result as 0, not -0. Given that the point of template tags and
filters is to make data more human-readable, I think returning

"0"

is preferable in this case than returning "-0".


If this ticket is reopened, I'll be happy to submit a patch for

it.


Cheers,

Sky

--
You received this message because you are subscribed to the

Google

Groups "Django developers  (Contributions to Django itself)"

group.

To unsubscribe from this group and stop receiving emails from

it,

send an email to django-developers+unsubscr...@googlegroups.com.

To view this discussion on the web visit







https://groups.google.com/d/msgid/django-developers/aec9450abcb511a0bb4a020c770a0483%40skychristensen.com.


--
You received this message because you are subscribed to the

Google

Groups "Django developers  (Contributions to Django itself)"

group.

To unsubscribe from this group and stop receiving emails from it,
send an email to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit






https://groups.google.com/d/msgid/django-developers/1F8DEBF9-FBEB-4A1C-BE3B-CA9D4507E702%40kye.id.au.


--
Adam

--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it,

send

an email to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit




https://groups.google.com/d/msgid/django-developers/CAMyDDM3FhTEUmWmpHaAqHuRxCbqHJcH6riS9vQ%2BNjhx3LcGhPA%40mail.gmail.com

[1].


Links:
--
[1]




https://groups.google.com/d/msgid/django-developers/CAMyDDM3FhTEUmWmpHaAqHuRxCbqHJcH6riS9vQ%2BNjhx3LcGhPA%40mail.gmail.com?utm_medium=email&utm_source=footer


--
You received this message because you are subscribed to the Google
Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit


https://groups.google.com/d/msgid/django-developers/f11994750333b35688ad5f8053e1f13f%40skychristensen.com.

--
Adam

 --
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAMyDDM2jQXp3FDjmiHzYoxWM069%3D6royttHd6Av8a4GUT%3DpYmA%40mail.gmail.com
[1].


Links:
--
[1]
https://groups.google.com/d/msgid/django-developers/CAMyDDM2jQXp3FDjmiHzYoxWM069%3D6royttHd6Av8a4GUT%3DpYmA%40mail.gmail.com?utm_medium=email&utm_source=footer


--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/53382700596b014f65d61f94a9d8d872%40skychristensen.com.

Re: Stalled tickets

[ludovic coues]

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, 01:45 David Vaz  wrote:

> Hi,
>
> I am playing around at the DjangoCon US 2019 Sprints and while trying to
> do my share one thing stands out in the open tickets is: Some are very old
> and others have not been touched in a while.
>
> I did a simple analysis of accepted and open tickets based on last
> modified time (kind of a live status).
>
> The numbers might change over time, but I also linked them:
>
> Modified at any time All
> :
> 1264
>
> Modified in last 5 years
> :
> 1039
>
> Modified in last 4 years:
> 
> 887
>
> Modified in last 3 years
> :
> 728
>
> Modified in last 2 years
> :
> 494
>
> Modified in last year
> :
>329
>
>
> So if we would decide to close stalled tickets after some inactivity
> period we could massively reduce the opened tickets list. Imagine if we
> close any ticket no modified in the last 5 years we would reduce by 20% the
> active ticket list. If we decide to be more aggressive, say 3 years we can
> cut by half the active tickets list.
>
>
> I also believe that apparently stalled tickets might be important. This
> auto-close approach would also trigger *a live prof, *any automatically
> closed ticket could be reopened if relevant.
>
>
> Let us focus the efforts on the really active ones.
>
>
> Anyway, these are just my thoughts.
>
>
> For those of you who do not know me, I am organizing DjangoCon Europe 2020
> in Porto Portugal and you are all invited, official details are about to be
> released.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/b3b855e5-7fd6-4b26-b365-75ff687c4b4c%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEuG%2BTYPvHMVHL9ZEy5fTsA%2Bfj7L_sisehVcRiQbgJF9eKTXsg%40mail.gmail.com.