Re: Proposal: remove triage stage someday/maybe

[Russell Keith-Magee]

On Sun, Aug 18, 2013 at 4:10 PM, Wim Feijen  wrote:

> Hi,
>
> When triaging tickets I came across the triage stage Someday/Maybe. The
> docs say I shouldn't use it. :) I think they are right.
>
> For me triaging tickets is all about making a decision. I make a choice
> between either: "yes, good idea", or "no, we definitely don't want that".
> Someday/maybe seems like not a good choice here, because it leaves things
> in the uncertain.
>
> Therefore, I'd like to propose to remove this triage stage, like we did
> with design decision needed.
>
> Currently, there are 47 tickets marked as someday/maybe. Looking over
> them, it seems to me that:
> 1. most can be marked as Accepted. A solution may or may not be hard to
> find but we accept that django could improve here.
> 2. some should actually be marked as won't fix but weren't out of
> hospitality.
>
> What is your opinion?
>

I'm not sure I agree.

DDN was being variously used as "accepted, but we need to work on the
design" and "don't know if we want to accept this". This meant it ended up
being an area where we punted on making hard decisions.

However, "Someday/Maybe" are ideas that have been accepted, but are
dependent on large pieces of work (like schema migrations or composite
keys), or large backwards incompatibilities. If the dependencies land, or
someone can work out a way around the backwards incompatibility problem,
then they could move back to "accepted".

Yes, we could just mark these all as "accepted". However, IMHO the
"Someday/Maybe" marker provides a useful indicator to the community -- that
this feature isn't going to land any time soon. Look at any long term
accepted ticket, and there will be a "when will this be fixed in trunk"
comment; "Someday/Maybe" gives a pre-emptive answer to this question.

I'm -0 to removing Someday/Maybe.

If there are tickets in Someday/Maybe that should be marked wont fix, or
should be in accepted (because there's no architectural reason that they
couldn't be implemented right now), please call them out -- it's entirely
possible there are some tickets in there that need to be reassessed.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Revisiting multiline tags

[Russell Keith-Magee]

On Sun, Aug 18, 2013 at 3:57 PM, Wim Feijen  wrote:

> Hi Jacob and Adrian,
>
> Reading this long thread with many +1s makes me think of truncatechars
> which is not a good feeling.
>

It's important to remember that the truncatechars example wasn't anywhere
near as simple as the original proposal suggested (or proponents continual
insisted). Most proposals for a truncatechars command implemented
"value[:n]", and if you look at the solution that was accepted, the
solution acceptable to core was a *lot* more complex than that due to
unicode issues.

The truncatechars issue is also from a time when the core team was a lot
smaller than it is today, so the bandwidth that was available to spend was
pretty low; combine this with the fact that the core team members at the
time didn't really like the idea from an aesthetic sense, and the idea got
stalled.

That said -- I hear you: you don't want to see a repeat of truncatechars as
an example of the core team interacting with the community. However, I
think the example here is different (at least, it is from my perspective).

In the case of truncatechars, there was a reasonable solution, the core
team indicated what it was, but also indicated they weren't going to spend
time building it themselves. End users who *really* wanted to use the
value[:n] solution could add it as a custom tag and use it in about 5 lines
of code (which was also a big reason why the core team didn't give the
issue much thought).

In this case, we're discussing a fundamental design decision of the
template language. There is no "right" answer here -- there's only the
design considerations for both sides of the argument. Allowing multiline
tags will have a profound impact on what Django templates look like in the
wild, and to date, the core team hasn't been convinced that the cost is
exceeded by the benefit that is  gained by constraining them.


> I wondered if you are using internationalisation? If so have you run into
> the same problems or is it easy to circumvent for you?
>

I'm not using it myself, so can you clarify how multiline tags affects
internationalization?

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Proposal: A diagram showing Class Based View inheritance and mixins.

[Seth Moon]

I believe it would be beneficial to the Django developers and users if the 
documentation included a diagram showing the complete structure of how 
Class Based Views get their functionality. This would be a relatively 
simple diagram that shows the classes each generic view inherits from. The 
reason I am proposing this is because the current state of Generic Class 
Based Views is too complex for many people, myself included, with some 
views inheriting from 9 other classes (CreateView, UpdateView) down a long 
chain of both single and multiple inheritance. This would also enable 
people to gain a deeper understanding of why the Views are structured the 
way they are, and encourage people to explore the available BaseViews and 
mixins in order to assemble more customized applications without having to 
reinvent the wheel.

I posted this on the Django Reddit 
communitywith
 relative success being the top post. There is a 
DIA  diagram file and SVG available on a 
Google 
Drive 
folderthat 
is publicly accessible for you to download and modify. Version 3 is 
the most current revision and differs extensively from what I originally 
posted on Reddit.

A preview of the diagram can be seen below (It's a fairly large image):



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: remove triage stage someday/maybe

[Cal Leeming [Simplicity Media Ltd]]

+1

On Sun, Aug 18, 2013 at 3:57 PM, Tim Graham  wrote:

> I think the state is useful because it provides a way to filter out
> tickets that are not immediately actionable (for example, there are several
> tickets that suggest schema migrations). When migrations land in core, we
> can then "accept" these tickets.
>
>
> On Sunday, August 18, 2013 4:10:14 AM UTC-4, Wim Feijen wrote:
>>
>> Hi,
>>
>> When triaging tickets I came across the triage stage Someday/Maybe. The
>> docs say I shouldn't use it. :) I think they are right.
>>
>> For me triaging tickets is all about making a decision. I make a choice
>> between either: "yes, good idea", or "no, we definitely don't want that".
>> Someday/maybe seems like not a good choice here, because it leaves things
>> in the uncertain.
>>
>> Therefore, I'd like to propose to remove this triage stage, like we did
>> with design decision needed.
>>
>> Currently, there are 47 tickets marked as someday/maybe. Looking over
>> them, it seems to me that:
>> 1. most can be marked as Accepted. A solution may or may not be hard to
>> find but we accept that django could improve here.
>> 2. some should actually be marked as won't fix but weren't out of
>> hospitality.
>>
>> What is your opinion?
>>
>> Wim
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: remove triage stage someday/maybe

[Tim Graham]

I think the state is useful because it provides a way to filter out tickets 
that are not immediately actionable (for example, there are several tickets 
that suggest schema migrations). When migrations land in core, we can then 
"accept" these tickets.

On Sunday, August 18, 2013 4:10:14 AM UTC-4, Wim Feijen wrote:
>
> Hi,
>
> When triaging tickets I came across the triage stage Someday/Maybe. The 
> docs say I shouldn't use it. :) I think they are right. 
>
> For me triaging tickets is all about making a decision. I make a choice 
> between either: "yes, good idea", or "no, we definitely don't want that". 
> Someday/maybe seems like not a good choice here, because it leaves things 
> in the uncertain. 
>
> Therefore, I'd like to propose to remove this triage stage, like we did 
> with design decision needed.
>
> Currently, there are 47 tickets marked as someday/maybe. Looking over 
> them, it seems to me that:
> 1. most can be marked as Accepted. A solution may or may not be hard to 
> find but we accept that django could improve here.
> 2. some should actually be marked as won't fix but weren't out of 
> hospitality. 
>
> What is your opinion?
>
> Wim
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Proposal: remove triage stage someday/maybe

[Wim Feijen]

Hi,

When triaging tickets I came across the triage stage Someday/Maybe. The 
docs say I shouldn't use it. :) I think they are right. 

For me triaging tickets is all about making a decision. I make a choice 
between either: "yes, good idea", or "no, we definitely don't want that". 
Someday/maybe seems like not a good choice here, because it leaves things 
in the uncertain. 

Therefore, I'd like to propose to remove this triage stage, like we did 
with design decision needed.

Currently, there are 47 tickets marked as someday/maybe. Looking over them, 
it seems to me that:
1. most can be marked as Accepted. A solution may or may not be hard to 
find but we accept that django could improve here.
2. some should actually be marked as won't fix but weren't out of 
hospitality. 

What is your opinion?

Wim

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Revisiting multiline tags

[Wim Feijen]

Hi Jacob and Adrian,

Reading this long thread with many +1s makes me think of truncatechars 
which is not a good feeling. 

I wondered if you are using internationalisation? If so have you run into 
the same problems or is it easy to circumvent for you?

Or am I missing something and are all these programmers plainly doing it 
wrong?

Wim

On Monday, 15 July 2013 23:41:25 UTC+2, Jacob Kaplan-Moss wrote:
>
> On Mon, Jul 15, 2013 at 1:34 PM, Daniel Ellis  > wrote:
>
>> Is it considered gauche to revive old topics such as this?  
>
>
> It's not, but my opinion hasn't changed -- I'm still -1, and so's Adrian. 
> So unless you've got something really convincing, an argument that hasn't 
> been presented yet that is totally going to change both of our minds -- 
> it's probably not worth your time.
>
> Jacob
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.