Re: Added signals that runs when adding an object to a Many-To-One relation

[Paul Egges]

Good to know.

Thanks,

Paul


On Fri, Feb 3, 2017 at 10:03 AM, Oskar Persson 
wrote:

> No, the save method isn't called unless you specify bulk=False
> 
>
> Den fredag 3 februari 2017 kl. 17:53:04 UTC+1 skrev mtnpaul:
>>
>> I thought a Many-To-One would not require an intermediate table, so it
>> would be caught by pre-save and post-save on the object containing the
>> Foreign Key. Is that not true?
>>
>>
>> Paul
>>
>> On Fri, Feb 3, 2017 at 8:28 AM, Oskar Persson 
>> wrote:
>>
>>> Hi everyone.
>>>
>>> I've created a pull request (8018)
>>>  that adds the signals
>>> pre_add and post_add that are triggered when adding an object to a
>>> Many-To-One relation. The reason for this PR is to provide a simple (is
>>> there any other?) way to run custom code when ever adding an object to a
>>> Many-To-One relation. There already exists a signal for Many-To-Many
>>> 
>>> fields so why not for Many-To-One?
>>>
>>> What are your thoughts on this?
>>>
>>>
>>>
>>> Thanks
>>>
>>> Oskar Persson
>>>
>>> --
>>> 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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/django-developers/249d697b-f030-4112-a192-2c8510461f5b%
>>> 40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/e6e9a557-44f0-4489-bc11-
> baae40e35930%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAD4jHO%2Bd8ynm3zG23m0FBgE-mScgOxZfv%2BzhNaiyajMbAQp7Pw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Added signals that runs when adding an object to a Many-To-One relation

[Paul Egges]

I thought a Many-To-One would not require an intermediate table, so it
would be caught by pre-save and post-save on the object containing the
Foreign Key. Is that not true?


Paul

On Fri, Feb 3, 2017 at 8:28 AM, Oskar Persson 
wrote:

> Hi everyone.
>
> I've created a pull request (8018)
>  that adds the signals
> pre_add and post_add that are triggered when adding an object to a
> Many-To-One relation. The reason for this PR is to provide a simple (is
> there any other?) way to run custom code when ever adding an object to a
> Many-To-One relation. There already exists a signal for Many-To-Many
>  fields
> so why not for Many-To-One?
>
> What are your thoughts on this?
>
>
>
> Thanks
>
> Oskar Persson
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/249d697b-f030-4112-a192-
> 2c8510461f5b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAD4jHOKKU55wSmsA9YYySAPJSRj8LCgXWuThfzKNtLx2CRRkPQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Paul Egges]

Actually, we do something very similar to this in a routes.py for a flask
app. Except instead of "pass" we call a function that has been imported.

Paul



*Flask*
> Doesn't really have the idea of putting all your routes in one spot. So
> pardon the silly example.
>
>
> @app.route('articles/2003/')
> def special_case_2003():
>   pass
>
> @app.route('articles//')
> def year_archive(year):
>   pass
>
> @app.route('articles///')
> def month_archive(year, month):
>   pass
>
> @app.route('articles')
> def article_detail(year, month, day):
>   pass
>
> @app.route('articles//')
> def slug_view(slug):
>   pass
>
>

-- 
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/1177f3c9-fe36-41b4-b6b3-
> 69daae8d8409%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAD4jHOKtBtgV7VQ-v1%3DOy%3DpJmO15mbg%3D8Agu%3DoDaDKq0APxiaw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

[Paul Egges]

Yeah, I was referring to the post by Daniel at the start of the thread, not
Reid's comment.

I would be -1 on changing the check of usernames at login to
case-insensitive. But I would be +1 with preventing the creation of new
usernames which would match existing usernames in a case-insensitive manner.

On Wed, Oct 21, 2015 at 3:39 PM, Shai Berger  wrote:

> Hi,
>
> On Thursday 22 October 2015 00:01:24 Paul Egges wrote:
> > Perhaps I'm missing something, but this would not change current users,
> > only the creation of new users. It seems that logins would still be case
> > sensitive.
>
> Not the way Reid presented it:
>
> > > Le mercredi 21 octobre 2015 15:44:55 UTC-4, Reid Ransom a écrit :
> > >> Is it reasonable to consider changing the default for usernames to be
> > >> case-insensitive in 2.0?
>
> I think, though, it would be easy enough for us to provide a new, case-
> insensitive base class for users, and change the recommendations in our
> documentation to tell users to inherit that rather than the current
> AbstractBaseUser and AbstractUser. We could also write a simple management
> command to validate lower-case uniquness and turn all usernames to
> lowercase,
> as preparation for changing the login and registration logic.
>
> These could all be done outside of core, and perhaps they should be -- the
> only point I see for including them in core is the risk that, as a
> developer,
> if core doesn't make you think about it from the get-go, by the time you
> decide to make the change you may be stuck with conflicting (lower-case
> equal)
> usernames in your database. But frankly, I would guess that this problem
> does
> not really occur very often; that for most sites, if they decide to switch
> to
> case-insensitive usernames, there would be no problem.
>
> Regretfully, we can't just switch Django to do that, because of the few
> sites
> who will have a problem, and no clear upgrade path.
>
> Shai.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAD4jHOKk3p6kh7sRrUp4G6JxCA-CpeV7bhuABE0PwSUBW8EO-w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

[Paul Egges]

Perhaps I'm missing something, but this would not change current users,
only the creation of new users. It seems that logins would still be case
sensitive. It would just prevent new users from being created that would
match in a case insensitive manner with an existing user. For example
existing users:

SomeUser and someuser could still use the site in the same manner as the
login process would still be case sensitive. But a new user could not
signup with a username of someUser.



On Wed, Oct 21, 2015 at 1:59 PM, charettes  wrote:

> Hi Reid,
>
> 2.0 is not planned to be a special release in regard to backward
> compatibility.
>
> Since this is a backward incompatible change (what should be done with
> duplicate usernames, etc.) I doubt it's going to happen.
>
> Simon
>
> Le mercredi 21 octobre 2015 15:44:55 UTC-4, Reid Ransom a écrit :
>>
>> Is it reasonable to consider changing the default for usernames to be
>> case-insensitive in 2.0?
>>
>> On Sunday, August 30, 2015 at 12:11:35 PM UTC-4, Collin Anderson wrote:
>>>
>>> I propose adding a check on UserCreationForm (used by the admin). The
>>> current implementation relies on the model fields unique=True check which
>>> is case-sensitive (except on mysql).
>>>
>>> Whenever I've made a login form, I've always used or made a copy of or
>>> at least studied UserCreationForm. I think if we had a nice walk through of
>>> how to create your own form which included the iexact hint, I think that
>>> would also help solve this problem.
>>>
>>> On Sun, Aug 30, 2015 at 6:43 AM, Florian Apolloner 
>>> wrote:
>>>


 On Saturday, August 29, 2015 at 9:59:30 PM UTC+2, Tim Graham wrote:
>
> The suggested change is to not allow a new user if there's a
> username__iexact match.
>

 Yes, but as change to what? To the admin interface? this will only
 cover admin usage. To a full_clean of the user model [This is often not
 used anyways]? I am somewhat against that…

 --
 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-develop...@googlegroups.com.
 To post to this group, send email to django-d...@googlegroups.com.
 Visit this group at http://groups.google.com/group/django-developers.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/django-developers/650405a3-c860-4d84-be94-5b6a6c779aa2%40googlegroups.com
 
 .

 For more options, visit https://groups.google.com/d/optout.

>>>
>>> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/a7c3add7-d13d-4b5c-af73-ac74cbc1c6a0%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAD4jHOLL_PqyERHO4ypx-j%3Dp8K%3Dz1vZc8jBo1roZh_LL2zHWag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Paul Egges]

Mark me a +1 on this as well.  Many of us don't ask for items in discussion
that have been marked as "won't fix" because we don't realize that the
decisions on these items can be reversed.

Thanks,

Paul

On Fri, Feb 24, 2012 at 2:19 AM, Bradley Ayers wrote:

>
> On 24/02/2012, at 7:01 PM, Stephan Jaensch  wrote:
>
> >>> 1) It's an easy fix.
> >>> 2) It's backwards compatible.
> >>> 3) It has no impact on performance.
> >>> 4) LOTS of people want it.
> >>>
> >>> and most importantly
> >>>
> >>> 5) We could stop asking for it.
> >>>
> >>> This issue is such an easy "sure, why not!?"
> >>>
> >>> Please, O benevolent dictators, listen to the populous, and heed their
> >>> cry.
> >>
> >> I can certainly appreciate the reasons why those asking for this change
> would like to see the change made, but please don't attempt to characterize
> this thread as clear and overwhelming support for change.
> >>
> >> This thread contains 6 people expressing support for this change, and 2
> against (a BDFL, a core developer) -- and you can add me to the -0 list.
> There are over 6000 subscribers to django-developers. I put it to you that
> the vast majority of people haven't expressed an opinion -- and many of
> those haven't expressed an opinion because they're happy with (or
> indifferent to) the status quo, and a BDFL has already indicated that the
> status quo is his preferred option.
> >
> > You asked for it, so here is my +1.
> >
> >> This is also the first time the issue has been raised on django-dev for
> some time -- I can't even remember the last time the subject was raised. If
> this is such a demand of the populous, why isn't it a regular topic of
> discussion on django-dev?
> >
> > Because the Django community is extremely nice and well-behaved...? :) I
> too was unhappy with the decision, but didn't feel it was important enough
> to post in this thread. That doesn't mean I wouldn't appreciate multiline
> tags.
> >
> >> Finally, your arguments in favor of making this change are almost
> entirely technical -- easy fix, backwards compatible, no performance hit.
> However, you've missed the non-technical aspects -- that introducing
> multiline tags would fundamentally change the flavor of Django templates.
> Part of the job of the BDFLs is to make aesthetic choices. As indicated by
> Adrian in his response, this is largely an aesthetic decision on his part.
> Aesthetic choices aren't always popular, and almost by definition won't
> make everyone happy, but they are an essential part of what gives Django
> it's distinctive flavor.
> >
> > Well, and you are really making the non-technical argument for the
> supporters, aren't you? If multiline tags would fundamentally change the
> flavor of Django templates, it would mean that suddenly people everywhere
> would start using them, massively. This would mean there is overwhelming
> demand for them. But if people do only use them in the cases where it's
> appropriate (e.g. the dreaded trans tag, multi-line comments and so forth)
> then it doesn't change much of anything and just makes templates more
> readable.
> >
> > I understand this is an aesthetic decision. I just wish to point out
> that you can't make the argument that nobody wants it and that it would
> also have a big impact.
> >
> > Cheers,
> > Stephan
>
> In the interest of making the wider community opinion heard, I too am +1
> on this, my feeling is exactly the same as Stephen.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: start using less (and bootstrap!)

[Paul Egges]

On Thu, Feb 2, 2012 at 2:16 PM, Adam "Cezar" Jenkins  wrote:

>  ...
>
As far as core. Bootstrap should be a 3rd party app, but possibly having
> less support in core might be helpful.
>
>
>
Funny how that reads. Perhaps for clarity it should say but ' ... possibly
having support for "less" in core might be helpful.'  But then again, my
English usually leaves a lot to be desired.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: drop Python 2.5 support in Django 1.5

[Paul Egges]

+1

I thought there was an implicit understanding that only 3 versions of
Python would be supported at any given time.  If so it makes sense to drop
support for 2.4 when we add 3.x.



On Sat, Dec 10, 2011 at 9:22 AM, Jannis Leidel  wrote:

> > I propose that we attempt to merge the py3k work after the release
> > of 1.4, rather than let it go stale and lose the good work done so far,
> > and also drop support for Python 2.5 for Django 1.5.
>
> +1
>
> I think dropping Python 2.5 in the process of porting Django to Python 3.X
> are reasonable goals. That said, even without the Py3k work going so well I
> would support dropping Python 2.5 in the next major version.
>
> Jannis
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Python 3 port - all tests now pass on 2.7.2 and 3.2.2 with the same codebase

[Paul Egges]

I was thinking the same thing. Make absolutely sure it works under 2.5-2.7
and even if there are a couple of issues or items not fully tested under
3.2.2 at least we will be moving in the right direction.

paul

On Fri, Dec 9, 2011 at 5:21 PM, Joseph Tennies  wrote:

> I must say that I would personally LOVE to see this in 1.4 as some sort of
> "preview" (akin to __future__) to give people a chance to get their
> packages up and running on Python 3. This would also allow people to
> document the porting process properly.
>
> Obviously, this is dependent on the code passing
>
>
>
> -- Sent from my Palm Pixi
>
> --
> On Dec 9, 2011 2:26 PM, Ram Rachum  wrote:
>
> In which Django release are we hoping to release this port? 1.4 or 1.5?
>
>
> Ram.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/Y8-2tS9lth4J.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: please reopen ticket 15567

[Paul Egges]

On Tue, Sep 13, 2011 at 12:27 PM, Anssi Kääriäinen
wrote:

> On Sep 13, 8:24 pm, Adam Jenkins  wrote:
> > +1 on making the error say more than incorrect username/password. That
> > is confusing. In regards to leaking information about the user. The
> > error message in general could be changed to something like this, of
> > course with better wording:
> >
> > "Username and password incorrect or access to this page restricted".
>
> +1. This solves the problem nicely. the login does not leak
> information and the error message is correct.
>

I'm also +1 on this solution. Although maybe "is" should be inserted before
the word restricted.

Paul


>
>  - Anssi
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: switch to HTML5 for bundled templates

[Paul Egges]

I agree completely that we should move to HTML5. It seems like it will be
even more important as more and more people use Smart Phones or Pads for
surfing the net, and I believe all of these are supporting HTML5.  I've
started attending some HTML5 user group meetings, and I'm quite impressed
with the tools/libraries available for development.

Paul

On Mon, Mar 28, 2011 at 10:46 AM, Carl Meyer  wrote:

> Hi Luke,
>
> On 03/28/2011 12:38 PM, Luke Plant wrote:
> > Overall, I think the advantages outweigh the disadvantages, that we have
> > to make the move sometime, and now is about the right time, or perhaps
> > slightly late.
>
> 100% agreed, for all the reasons you outlined. We've been using the
> HTML5 doctype exclusively for a year and a half already, with no issues,
> and quite a lot of benefits (i.e. Firefox 4 and latest Chrome will now
> do client-side validation of things like input type="email").
>
> It's quite clear by now that HTML5 is the future, we may as well get on
> board sooner rather than later.
>
> Carl
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Process discussion: reboot

[Paul Egges]

This sounds like a great idea to me.

+1 for me.  I've a been a bit reluctant to up my participation for a variety
of reasons, but kind of knowing how best to proceed is one of the large
ones.

Thanks,

Paul

On Tue, Apr 20, 2010 at 10:43 AM, Stephen Crosby wrote:

> What could be very helpful here is some education for would-be Django
> developers. The tutorial format has worked so well for educating new Django
> users, why not apply it also to Django developers also? After the 1.2
> release, why don't we come up with a Django developers tutorial that walks
> us through the process of solving issues and working on Django. The goal of
> this would be to help would-be developers understand the Django development
> process by getting their hands dirty with a real issue.
>
> It could begin with a short explanation of the process, go through finding
> a real (old) example issue in Trac (already solved), it could run down what
> type of Trac activity is helpful and what is not. Then the tutorial could
> instruct the reader to checkout an old revision of Django (with the unsolved
> issue) and how to reproduce the issue.
>
> We could show the reader how to apply a bad patch (attached by some
> less-informed Trac user), then how to run the test suite and notice that
> some tests fail. Some instruction on how to politely note that fact on Trac
> might be in order as well as how the patch was rewritten in order to pass
> the tests.
>
> Another bit on proper documentation, some notes on quality, where to get
> help, what types of issues need discussion on this list would be great and
> I'm sure there's more that could be included with this type of tutorial.
>
>
> On Tue, Apr 20, 2010 at 9:09 AM, Jacob Kaplan-Moss wrote:
>
>> On Mon, Apr 19, 2010 at 3:34 PM, Gabriel Hurley  wrote:
>> > When I finally did submit my first patch, I was terrified of getting
>> > it wrong and having it rejected. I'd seen it happen on other tickets.
>> > It wasn't until I got *more involved* and started keeping up with the
>> > trac timeline--watching the ebb and flow of tickets--that I started to
>> > understand how the tone on trac had a reason. Until you get that
>> > perspective, it's hard to know what's right or wrong, and easy to take
>> > things personally. The core devs can seem imposing or scary simply
>> > because you don't know them.
>>
>> This is *really* good feedback, and thank you very much for it.
>>
>> Clearly scaring people isn't our intent, but if that's the result...
>> well, we're doing something wrong. I really don't want people to be
>> scared off, and I'm hearing from you and a few others that that's
>> already happening.
>>
>> I don't think I need to enumerate why the tone on a ticket tracker
>> tends towards the terse -- lack of time, repetition, yadayada -- but
>> regardless I don't like our process being scary.
>>
>> > If anything, my point is that getting started as a Django contributor
>> > *can* be difficult, and the core team just being aware of that fact is
>> > a good thing.
>>
>> I hear you loud and clear, and I'd love any suggestions you might have
>> about how we might improve in this area.
>>
>> Jacob
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>
>
> --
> Stephen Crosby
> Web Developer
> lithostech.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.