Re: Suggestion: a new "nature" field in Trac

2011-02-22 Thread Julien Phalip 
On Feb 21, 4:35 pm, Gabriel Hurley  wrote:
> I'm still in favor of adding the "needsinfo" resolution and would love to
> see that happen... I guess technically I could even do that one myself via
> Trac's web admin if we're all agreed on it.

I agree this is a good idea. By the way, for reference it is #14702.

> I'm ambivalent about adding the "ticket type" field back in, though. It can
> be useful, but it *is* an extra item to keep managed and argue about... My
> bigger concern, though, is the 1700+ existing tickets which will be
> uncategorized. It would end up meaning that using that flag for queries in
> Trac wouldn't give you a complete picture (at least not for a very long time
> while things catch up).

I share your concern about the existing tickets but I think that
things would catch up reasonably quickly. This would be mostly helpful
in conjunction with the milestone flag for coordinating the alpha,
beta and final releases in the future (There seems to have been "only"
about 2-300 tickets floating around for 1.3 in recent months). Perhaps
this is something that could be trialled for the next cycle until the
1.4 release and see whether it helps or not.

While I'm at it, I've also recently felt there was a gap between the
"Accepted" and "Ready for checkin" stages, which might coincide with
the 'needs feedback' state that Russell has mentioned in an earlier
reply to this thread. When one posts a patch and believes that it is
correct (or closed to be so), there is no easy and persistent way to
request that someone else review the patch and then potentially
promote it to RFC. Currently the only ways are transient (e.g. posting
on the django-dev mailing list or IRC channel) and as such not very
efficient if no one is both interested and available exactly at that
time.

RFC'ing one's own patch is bad form unless the patch is absolutely
straightforward, and more generally it is always better to have an
extra pair of eyes cast over it. I fear that because of this gap in
the process, too many good patches go unnoticed and then grow stale or
forgotten, whereas had those been staged to, for example, "Patch ready
for review" they would have gotten noticed, reviewed and eventually
checked-in much quicker.

I know there already is a "Has patch" flag, but I actually find that
one a bit useless since there's no way to distinguish from the mass of
tickets where there are good, solid patches (whose authors themselves
think could be RFC or simply in need for review) versus the draft or
tentative patches. In fact, I'd make both the "Has patch" and "Patch
needs improvement" flags redundant and instead introduce a new "Patch
ready for review" stage.

Here's a typical example scenario:

- A reports a bug #123.
- B verifies the bug and stages #123 to "Accepted".
- B posts a patch and is pretty confident it works. B then stages #123
to "Patch ready for review".
- C has a few minutes on his hands and pulls the list of tickets with
patches ready for review, opens #123, scans the patch and sees a few
issues. C stages #123 back to "Accepted" (or in fact may as well leave
it as "Patch ready for review") and writes a comment explaining the
issues with the patch.
- B posts a new updated patch (and re-stages #123 to "Patch ready for
review" if it has been staged back to "Accepted").
- D verifies the patch is now correct and then stages #123 to "RFC".

To illustrate this, I've got two patches currently in this virtual
"Patch ready for review" state: #13091 and #12475 :-)

What do you think?

Julien

-- 
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: Suggestion: a new "nature" field in Trac

2011-02-22 Thread Russell Keith-Magee 
On Tue, Feb 22, 2011 at 3:49 PM, Julien Phalip  wrote:

> I know there already is a "Has patch" flag, but I actually find that
> one a bit useless since there's no way to distinguish from the mass of
> tickets where there are good, solid patches (whose authors themselves
> think could be RFC or simply in need for review) versus the draft or
> tentative patches. In fact, I'd make both the "Has patch" and "Patch
> needs improvement" flags redundant and instead introduce a new "Patch
> ready for review" stage.

This smells a bit like a bikeshed to me. What's the difference between
having a *state* that says "patch needs review" and a boolean flag
that says "patch needs review"?

A draft or tentative patch is a patch that the author has themselves
flagged as "needs improvement". Or, demonstrating the flexibility of
the system -- you could also treat that case by simply not flagging
the 'has patch' state. Either way, it is possible to provide a patch
without indicating that it is ready for review.

> To illustrate this, I've got two patches currently in this virtual
> "Patch ready for review" state: #13091 and #12475 :-)

#13091 isn't ready for review, because it's still marked DDN. That
means that a decision still needs to be made.

#12475 turns up here:

http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&needs_better_patch=0&needs_tests=0&needs_docs=0&has_patch=1&stage=Accepted&order=priority

... along with 313 other tickets. I've just added this query to the
"reports" page [1], which is itself linked from the
code.djangoproject.com home page. A range of other queries have always
been there, but there wasn't a simple "needs review" query.

[1] http://code.djangoproject.com/wiki/Reports

Like I have said many times in the past -- issuing queries to find
tickets needing review isn't a problem we have. The information that
is needed is all there. What we *do* have are two other problems:

 1) Finding people willing to be altruistic and review someone else's
work, rather than their own
 2) Directing people who are inclined to be altruistic to the right place.

I know that UX can affect engagement, so it's entirely possible that
the whole Trac process is an impediment to engagement of potential
reviewers. However, I strongly challenge the assertion that either of
these problems can be fixed by simply adding a triage states alone. A
triage state just changes the query (arguably simplifying it) -- it
doesn't by itself increase the number of people volunteering.

The problem we have is a much deeper problem of community engagement.
Unfortunately, this is also problem that I don't have any magic
solutions for. Convincing people to be altruistic is hard.

A triage state also doesn't help people who *are* inclined to help to
actually find the information that would allow them to help. That
means the contribution guide, and the Trac reports page. Hopefully,
#14401 will address this somewhat. Either way, I don't think a Trac
flag will help -- it's a more fundamental IA problem for the project
itself (i.e., how to direct people to the right information).

One Trac feature that I suspect *might* help in this regard is one
that I've raised before -- allowing users to flag individual issues
that they have an interest in seeing solved. This isn't just another
flag, because it provides a way to slice and present the data in a
different way. It would allow us to provide a project-wide leaderboard
of the "most wanted bugs", providing a focus for volunteer activity
that doesn't currently exist. However, this requires someone to spend
time developing that feature for Trac, because it isn't (to my
knowledge) an out-of-the-box feature.

Yours,
Russ Magee %-)

-- 
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: Your thoughts on the Secure Web Application Framework Manifesto

2011-02-22 Thread Rohit Sethi 
Gabriel, great idea! This is a problem with OWASP in general, but
definitely we can do better on this doc. I think we'll first focus on
putting our words in action with help in contributing some of the
features into Django first, and then revisit the doc. Mainly I'd like
to assess what pieces of it are way too complex to implement as part
of a core framework, and which ones are viable. Once we revise the
list we'll look at ways to better present the data rather than a huge
single doc.

Thanks!

Rohit

On Feb 21, 11:31 pm, Gabriel Hurley  wrote:
> I've got one bit of feedback to offer on the document (which I did
> bookmark for future reference):
>
> Monolithic documents present a huge problem for finding, using and
> retaining information.
>
> A very useful and interesting extension of this type of project would
> be to work with people who have experience with information
> architecture and data visualization to find new ways of presenting
> this information. An interface that was simple, clear, interactive,
> layered and multi-faceted would make your manifesto into a drastically
> more valuable tool.
>
> I would love to be able to sit down with an interface to all the
> information you've gathered and "explore it". Ideally it would allow
> me to visually follow threads of commonalities in vulnerabilities, see
> clusters of the most common problem areas, and zoom in to the level of
> detail you've gathered on any individual item if I so choose.
>
> Either way, thank you for providing an interesting resource.
>
> All the best,
>
>     - Gabriel Hurley
>
> On Feb 21, 5:09 pm, Rohit Sethi  wrote:
>
>
>
>
>
>
>
> > Russell, awesome feedback. Thanks for being candid. We are on the same
> > page that the manifesto is really not all that important in and of
> > itself: The document piece is really only designed to give frameworks
> > a platform to say "hey, these are what we support" so that web app
> > developers building security-sensitive apps get an idea of how much
> > help they'll get from various framework.
>
> > I didn't want to bring this up until I got at least one response, but
> > my team is busy seeing which manifesto requirements are:
>
> > a) Already being fulfilled by Django (great- no more work to be done!)
> > b) Have been fulfilled elsewhere (e.g. OWASP ESAPI for Python) and
> > could be built into Django
> > c) Have not yet been done
>
> > We'll be looking to address b) and c) by either porting or building
> > ourselves. We hope we can get your feedback on why some things aren't
> > being implemented (if we can't find a pre-existing discussion in
> > existing tickets and/or this group).
>
> > The manifesto is designed to only a starting point: it's taking
> > several vulnerabilities, beyond the OWASP top 10, into something
> > targeted specifically for frameworks. It's definitely not intended to
> > be implemented by every framework in the world - nor should it be.
>
> > So, we (myself and at least four of our developers) will be working
> > closely with the Django community. I will be watching the list closely
> > and providing feedback when I can.
>
> > Looking forward to working with you
>
> > Cheers,
>
> > Rohit
>
> > On Feb 21, 7:42 pm, Russell Keith-Magee 
> > wrote:
>
> > > On Mon, Feb 21, 2011 at 11:21 PM, Rohit Sethi  wrote:
> > > > Django devs, I wanted to thank you for a truly awesome framework.
> > > > Programming with Python, and web app dev in Django, is truly a
> > > > pleasure. Our company, Security Compass, uses Django quite
> > > > substantially internally.
>
> > > > We put together a document called the Secure Web Application Framework
> > > > Manifesto for the Open Web Application Security Project (OWASP) - see:
> > > >http://www.owasp.org/index.php/Projects/OWASP_Secure_Web_Application_...
>
> > > > I would love to get your feedback about this project. How much of this
> > > > is realistic and how much of it is pie in the sky? Is it relevant for
> > > > you? If not, how does this document need to change to become relevant?
> > > > Clearly, Django takes security seriously which is a major reason we
> > > > use it. Please feel free to be candid - if you think the document
> > > > sucks and could never be used, it's important you let us know that
> > > > too.
>
> > > Hi Rohit,
>
> > > A lot of effort has clearly gone into this document. I haven't gone
> > > through it with a fine-toothed comb, but it seems like a reasonably
> > > thorough discussion of security issues affecting web frameworks.
>
> > > However, if you're looking for frank feedback, here goes:
>
> > > Who exactly is the intended audience for this document? What is/are
> > > the action item(s) stemming from it?
>
> > > More broadly, what it is you are hoping to achieve by writing this 
> > > document?
>
> > > Reading between the lines, I'm guessing you would like to see every
> > > web framework in the world adhering to best practices, with no obvious
> > > and know security vulnerabilities. This is a laudable

Re: Suggestion: a new "nature" field in Trac

2011-02-22 Thread Yishai Beeri 
On Tue, 22 Feb 2011 13:22:30 +0200, Russell Keith-Magee  
 wrote:



On Tue, Feb 22, 2011 at 3:49 PM, Julien Phalip  wrote:
One Trac feature that I suspect *might* help in this regard is one
that I've raised before -- allowing users to flag individual issues
that they have an interest in seeing solved. This isn't just another
flag, because it provides a way to slice and present the data in a
different way. It would allow us to provide a project-wide leaderboard
of the "most wanted bugs", providing a focus for volunteer activity
that doesn't currently exist. However, this requires someone to spend
time developing that feature for Trac, because it isn't (to my
knowledge) an out-of-the-box feature.



Can't this simply be the "cc" field - or better yet a clone thereof  
dedicated to this "vote"?


--
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: Suggestion: a new "nature" field in Trac

2011-02-22 Thread Russell Keith-Magee 
On Tue, Feb 22, 2011 at 9:48 PM, Yishai Beeri  wrote:
> On Tue, 22 Feb 2011 13:22:30 +0200, Russell Keith-Magee
>  wrote:
>
>> On Tue, Feb 22, 2011 at 3:49 PM, Julien Phalip  wrote:
>> One Trac feature that I suspect *might* help in this regard is one
>> that I've raised before -- allowing users to flag individual issues
>> that they have an interest in seeing solved. This isn't just another
>> flag, because it provides a way to slice and present the data in a
>> different way. It would allow us to provide a project-wide leaderboard
>> of the "most wanted bugs", providing a focus for volunteer activity
>> that doesn't currently exist. However, this requires someone to spend
>> time developing that feature for Trac, because it isn't (to my
>> knowledge) an out-of-the-box feature.
>>
>
> Can't this simply be the "cc" field - or better yet a clone thereof
> dedicated to this "vote"?

I'm not sufficiently familiar with Trac's internals to say for
certain. CC would probably give enough detail for storage purposes,
but it's not just a matter of storing the CC's. We also need to be
able to query based on the aggregate count of CC's, and sort based on
that count, and possibly even browse the graph of CC's shared between
users.

This is one of those areas where we need someone to step up an
volunteer to do some Trac work and show us what is possible.

Yours,
Russ Magee %-)

-- 
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: Suggestion: a new "nature" field in Trac

2011-02-22 Thread Daniel Moisset 
On Tue, Feb 22, 2011 at 11:21 AM, Russell Keith-Magee
 wrote:
>
> This is one of those areas where we need someone to step up an
> volunteer to do some Trac work and show us what is possible.
>

If http://trac-hacks.org/wiki/VotePlugin is fine for the needs, I'm ok
with helping install it; although I need proper access to install it
in the django trac.

Same offer re #14702, given that I was the one pushing for it :)

Regards,
D.

-- 
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: Contributing Guide Request For Input

2011-02-22 Thread Waylan Limberg 
On Sat, Feb 19, 2011 at 6:49 PM, Gabriel Hurley  wrote:
> I've added a patch to ticket #14401 based on the contributions people made
> to the wiki. This is the final call for comments and review before it gets
> officially added.
> Thanks!
>     - Gabriel Hurley


I realize the docs don't generally link to specific wiki pages, but
following Russ's comment on another thread, it occurs to me that
perhaps it would make sense to point people to the "Reports" page were
they can find a number of useful trac queries to find tickets to work
on. I get the impression a number of people don't realize this page
exists then request that feature x be added to trac - only to have it
pointed out that feature y accomplishes the same thing. These requests
are often motivated by frustration that their pet ticket doesn't stand
out in trac queries - when they're just not trying the right queries.
Just a thought.

On Tue, Feb 22, 2011 at 6:22 AM, Russell Keith-Magee
 wrote:
>
> ... along with 313 other tickets. I've just added this query to the
> "reports" page [1], which is itself linked from the
> code.djangoproject.com home page. A range of other queries have always
> been there, but there wasn't a simple "needs review" query.
>
> [1] http://code.djangoproject.com/wiki/Reports
>

-- 

\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

-- 
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: Suggestion: a new "nature" field in Trac

2011-02-22 Thread Yishai Beeri 
On the same note, the Reports [1] page in the wiki contains several links  
under "Tickets by popularity", which attempt to do exactly this based on  
the existing CC field. However none of these links work - can anyone  
recall if they ever did?



[1] http://code.djangoproject.com/wiki/Reports

On Tue, 22 Feb 2011 16:36:10 +0200, Daniel Moisset  
 wrote:



On Tue, Feb 22, 2011 at 11:21 AM, Russell Keith-Magee
 wrote:


This is one of those areas where we need someone to step up an
volunteer to do some Trac work and show us what is possible.



If http://trac-hacks.org/wiki/VotePlugin is fine for the needs, I'm ok
with helping install it; although I need proper access to install it
in the django trac.

Same offer re #14702, given that I was the one pushing for it :)

Regards,
D.




--
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: Intermittent IOError exception raised and emailed to admins during file upload.

2011-02-22 Thread Drew Volpe 


It oddly seems to have stopped happening when we moved to staging.
It's a different server though the apache config is exactly the same
(the settings I sent in my previous message: mod_wsgi 3.2, embedded
mode, mpm worker). We also rolled out a few fixes in our mobile app so
it's possible it was being caused by a bug in the client. If I have a
chance after launch, I'll go back and run the old version and see I
can reproduce.


Drew


On Feb 15, 6:15 pm, Graham Dumpleton 
wrote:
> On Wednesday, February 16, 2011 5:16:01 AM UTC+11, Drew Volpe wrote:
>
> > https only
>
> Any chance you can do some tests, if you yourself can replicate it, of
> whether it fails when using straight http. Most times I have heard about
> this, it is somehow specifically related to use of https connection. There
> were some bugs in Apache SSL implementation but you seem to have reasonably
> new Apache and think problems were in slightly older versions of Apache.
>
> Graham
>
> > Apache/2.2.16 on Ubuntu 10.10 (32 bit)
> > Python 2.6.6
> > mod_wsgi 3.2  embedded mode
> > mpm worker:
> > 
> >     StartServers          2
> >     MinSpareThreads      25
> >     MaxSpareThreads      75
> >     ThreadLimit          64
> >     ThreadsPerChild      25
> >     MaxClients          150
> >     MaxRequestsPerChild   0
> > 
>
> > Right now, there's only 1-3 clients each making requests a few times
> > an hour.  Each request is a POST with typically only a few k of data.
>
> > The exception happens in the view as soon as request.raw_post_data is
> > accessed:
>
> >   File "/usr/lib/pymodules/python2.6/django/core/handlers/wsgi.py",
> > line 205, in _get_raw_post_data
> >     size=content_length)
> >   File "/usr/lib/pymodules/python2.6/django/core/handlers/wsgi.py",
> > line 69, in safe_copyfileobj
> >     buf = fsrc.read(min(length, size))
>
> > In my case, it's not a show-stopper as we now just catch the exception
> > and have the client retry (and the user never knows) but it sounds
> > similar to Tai's problem.
>
> > Dv
>
> > On Feb 14, 7:06 pm, Graham Dumpleton 
> > wrote:
> > > Presuming Apace/mod_wsgi is being used, are you using https or just http?
> > Are you using daemon mode of mod_wsgi? If yes to latter, how have you
> > configured daemon mode? Also what Apache MPM are you using and what MPM
> > configuration settings? Finally, what Apache and mod_wsgi versions are you
> > using?
>
> > > Graham
>
> > > On Tuesday, February 15, 2011 6:50:12 AM UTC+8, Drew Volpe wrote:
> > > > On Feb 14, 3:15 pm, Nick Phillips  wrote:
>
> > > > > > I'm seeing a similar issue in a eb service written in Django which
> > > > > > receives data from mobile apps as a POST.  Not infrequently, I'm
> > > > > > seeing the same "IOError: request data read error" when I try to
> > read
> > > > > > request.raw_post_data.  It happens more than spotty connections
> > would
> > > > > > explain.
>
> > > > > User double-clicks on submit button, second click killing the
> > connection
> > > > > created by the first press and starting another one?
>
> > > > In my case, the request is made in a background thread within a mobile
> > > > app (there's no form or webbrowser), so it's not that.  And I'm pretty
> > > > sure the mobile app is not killing the connection as it's able to push
> > > > data into another, similar API without any problems.
>
> > > > If Tai or anyone else found more information or data on this, I'd be
> > > > interested.

-- 
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: Suggestion: a new "nature" field in Trac

2011-02-22 Thread Julien Phalip 
On Feb 22, 3:22 am, Russell Keith-Magee 
wrote:
> On Tue, Feb 22, 2011 at 3:49 PM, Julien Phalip  wrote:
> > I know there already is a "Has patch" flag, but I actually find that
> > one a bit useless since there's no way to distinguish from the mass of
> > tickets where there are good, solid patches (whose authors themselves
> > think could be RFC or simply in need for review) versus the draft or
> > tentative patches. In fact, I'd make both the "Has patch" and "Patch
> > needs improvement" flags redundant and instead introduce a new "Patch
> > ready for review" stage.
>
> This smells a bit like a bikeshed to me. What's the difference between
> having a *state* that says "patch needs review" and a boolean flag
> that says "patch needs review"?
>
> A draft or tentative patch is a patch that the author has themselves
> flagged as "needs improvement". Or, demonstrating the flexibility of
> the system -- you could also treat that case by simply not flagging
> the 'has patch' state. Either way, it is possible to provide a patch
> without indicating that it is ready for review.
>
> > To illustrate this, I've got two patches currently in this virtual
> > "Patch ready for review" state: #13091 and #12475 :-)
>
> #13091 isn't ready for review, because it's still marked DDN. That
> means that a decision still needs to be made.
>
> #12475 turns up here:
>
> http://code.djangoproject.com/query?status=new&status=assigned&status...
>
> ... along with 313 other tickets. I've just added this query to the
> "reports" page [1], which is itself linked from the
> code.djangoproject.com home page. A range of other queries have always
> been there, but there wasn't a simple "needs review" query.
>
> [1]http://code.djangoproject.com/wiki/Reports

Thanks Russell, you've convinced me I was doing a little bike-shedding
there :-)
It does seem that some reports can already be generated to get the
results I was after.

> Like I have said many times in the past -- issuing queries to find
> tickets needing review isn't a problem we have. The information that
> is needed is all there. What we *do* have are two other problems:
>
>  1) Finding people willing to be altruistic and review someone else's
> work, rather than their own
>  2) Directing people who are inclined to be altruistic to the right place.
>
> I know that UX can affect engagement, so it's entirely possible that
> the whole Trac process is an impediment to engagement of potential
> reviewers. However, I strongly challenge the assertion that either of
> these problems can be fixed by simply adding a triage states alone. A
> triage state just changes the query (arguably simplifying it) -- it
> doesn't by itself increase the number of people volunteering.
>
> The problem we have is a much deeper problem of community engagement.
> Unfortunately, this is also problem that I don't have any magic
> solutions for. Convincing people to be altruistic is hard.
>
> A triage state also doesn't help people who *are* inclined to help to
> actually find the information that would allow them to help. That
> means the contribution guide, and the Trac reports page. Hopefully,
> #14401 will address this somewhat. Either way, I don't think a Trac
> flag will help -- it's a more fundamental IA problem for the project
> itself (i.e., how to direct people to the right information).
>
> One Trac feature that I suspect *might* help in this regard is one
> that I've raised before -- allowing users to flag individual issues
> that they have an interest in seeing solved. This isn't just another
> flag, because it provides a way to slice and present the data in a
> different way. It would allow us to provide a project-wide leaderboard
> of the "most wanted bugs", providing a focus for volunteer activity
> that doesn't currently exist. However, this requires someone to spend
> time developing that feature for Trac, because it isn't (to my
> knowledge) an out-of-the-box feature.

I'm voting +1 for the voting feature suggested by Daniel in his
previous reply to this thread.

As far increasing community engagement is concerned, off the top of my
head there are at least three things worth exploring:

1) Advertise

For example:

* The reports page is useful but it's easily missed. Perhaps there
should be a reminder and a link to it in every future sprint
announcements.
* There should be a huge "Contribute to Django" button (with round
cornerz) on the djangoproject.com homepage linking to more info (e.g.
to the page that Gabriel has been drafting recently).
* I believe the vast majority of django users come to the
djangoproject.com website primarily to view the documentation. So a
hard-to-miss "Contribute to Django" link could be displayed on every
single page of the doc.

2) Make the barrier for contribution seem lower.

Gabriel has already done an awesome job with the new "Contribute to
Django" page in the doc. The reports page is also great but could be
improved with more query links and more descriptive sce

'ascii' codec can't encode characters in position 0-8: ordinal not in range(128)

2011-02-22 Thread Alexander Bolotnov 
I created a simple model:

class Menu(models.Model):
name = models.CharField(null=False, 
blank=False,unique=True,max_length=50)
url = models.CharField(null=False, blank=False, 
unique=True,max_length=100)
sortOrder = models.IntegerField(null=False, blank=False, default=0)
def __unicode__(self):
return 'name: {0}, url: {1}'.format(self.name, self.url)

and hooked it to admin (all running on windows 7, django dev server)

now when I add a new item via admin and the name is in Russian (Like 
"коллекция картинок") it throws the following exception. How do I fix this?

UnicodeEncodeError at /admin/picviewer/menu/add/

'ascii' codec can't encode characters in position 0-8: ordinal not in range(128)

Request Method:POSTRequest URL:
http://127.0.0.1:8000/admin/picviewer/menu/add/Django Version:1.2.5Exception 
Type:UnicodeEncodeErrorException Value:

'ascii' codec can't encode characters in position 0-8: ordinal not in range(128)

Exception Location:D:\~Sasha\www.zavalen.ru\django\zavalen\picviewer\models.py 
in __unicode__, line 43Python Executable:D:\install\python27\python.exePython 
Version:2.7.1Python Path:['D:\\~Sasha\\www.zavalen.ru\\django\\zavalen', 
'C:\\Windows\\system32\\python27.zip', 'D:\\install\\python27\\DLLs', 
'D:\\install\\python27\\lib', 'D:\\install\\python27\\lib\\plat-win', 
'D:\\install\\python27\\lib\\lib-tk', 'D:\\install\\python27', 
'D:\\install\\python27\\lib\\site-packages']Server time:Tue, 22 Feb 2011 
23:24:58 +0300

-- 
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: 'ascii' codec can't encode characters in position 0-8: ordinal not in range(128)

2011-02-22 Thread Alexander Bolotnov 
I fixed this by change the unicode to return self.name - but why was this 
failing anyway?

-- 
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: 'ascii' codec can't encode characters in position 0-8: ordinal not in range(128)

2011-02-22 Thread rikuthero...@gmail.com 
The problem is, I think, that you're trying to insert a non-ascii string,
inside an ascii string:

def __unicode__(self):
return 'name: {0}, url: {1}'.format(self.name, self.url)

Probably, self.name is an unicode string, and you're trying to put it on a
non-unicode string. Try this:

def __unicode__(self):
return u'name: {0}, url: {1}'.format(self.name, self.url)

It may work. If it doesn't look for "smart_unicode" and "force_unicode"
Django functions.

Regards

2011/2/22 Alexander Bolotnov 

> I fixed this by change the unicode to return self.name - but why was this
> failing anyway?
>
> --
> 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.
>



-- 
Pablo Recio Quijano

Desarrollador Django
Yaco Sistemas - http://www.yaco.es/

-- 
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: 'ascii' codec can't encode characters in position 0-8: ordinal not in range(128)

2011-02-22 Thread Ian Kelly 
2011/2/22 Alexander Bolotnov 

> I created a simple model:
>
> class Menu(models.Model):
> name = models.CharField(null=False,
> blank=False,unique=True,max_length=50)
> url = models.CharField(null=False, blank=False,
> unique=True,max_length=100)
> sortOrder = models.IntegerField(null=False, blank=False, default=0)
> def __unicode__(self):
> return 'name: {0}, url: {1}'.format(self.name, self.url)
>
> and hooked it to admin (all running on windows 7, django dev server)
>
> now when I add a new item via admin and the name is in Russian (Like
> "коллекция картинок") it throws the following exception. How do I fix this?
>

Please direct questions about how to use Django to the django-users mailing
list.  This list is for development of Django itself.

Thanks,
Ian

-- 
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.

psycopg2.OperationalError: could not connect to server

2011-02-22 Thread ikars 


I installed the djangostack from bitnami last night, but have a hard getting 
psycopg2 to see postgresql. I get this instead:

*psycopg2.OperationalError: could not connect to server: No such file or 
directory*

* Is the server running locally and accepting*

* connections on Unix domain socket "/tmp/.s.PGSQL.5432"?*

*
*

Psql runs fine on its own and I can open the database
with it without a problem. SQLite3 runs fine as well if I reconfigure
settings.py for it...

I tried to follow this possible solution:
http://efod.se/blog/archive/2010/02/06/pscopg2-…
 but
postgresql seems to be listening to the right port already...

This is driving me nuts...


-- 
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: Pluggable encryption for django auth (design proposal)

2011-02-22 Thread Jeff Balogh 
On Mon, Feb 21, 2011 at 9:26 AM, Jacob Kaplan-Moss  wrote:
> On Mon, Feb 21, 2011 at 3:23 PM, poswald  wrote:
>> Russ, Carl, thanks for your feedback. Russ, I understand what you say
>> about not wanting to adopt crypto code because of the additional
>> responsibility. Unfortunately, there aren't very good options. Django
>> contrib.auth already makes the recommendation of SHA1 which we all
>> agree is less than ideal. There is simply no acceptable choice in the
>> python standard library. I also agree with Carl that PBKDF2 is
>> probably the most conservative option that qualifies as sufficient.
>
> I've been desperately trying to get up to speed on this stuff over the
> past few weeks. Crypto's very far from my strong suit, but I think I
> know enough now to agree. It seems to me we need two things:
>
> 1. A new, updated default for Django's password hashing. PBKDF2,
> perhaps, but whatever as long as it meets some basic requirements.
> 2. A mechanism to make swapping this hashing algorithm out easy(-ier).
> Again, details don't matter, requirements do.
>
> #1's a blocker for 1.4, I think, but if for some reason #2 can't be
> figured out I think it's ok to punt there for a bit longer. Ideally
> though they'd both go in at once.
>
> Now, I want to make very explicit my requirements here since we've
> gone 'round on this one a few times, so I'll lay out exactly what I'm
> going to want to see to get on board with any proposal. So:
>
> Requirements for a new password hash:
> * As little crypto code in Django as possible. We're not security
> experts, and we shouldn't try to be. Ideally would be something that
> leaves all of the dangerous parts to the stdlib. Perhaps we relax our
> dependency policy (we need to some day, I think, but that's a bigger
> argument maybe we shouldn't have now).
> * Any code we distribute gets audited by people who know what they're
> talking about.
> * Those people have reputations sufficient to convince me (or other
> core devs) that they know what they're doing. This is sorta a "who
> watches the watchers" moment, but we can't just trust someone who says
> they're a crypto expert; we have to believe them, too.

At Mozilla we've been trying to work out our ideal password storage
scheme for a little while. Spoiler alert: it doesn't involve bcrypt.

There's no code yet, but we have a little bit of documentation here:
https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines#Password_Storage.
This is the outline:

1. sha512 hashing
2. Per-user salt stored with the hashed password
3. Private system salt stored outside the database
4. The system salt can be deprecated if it gets leaked
5. Required minimum password length
6. Common passwords are blocked
7. Migrations towards more security are possible as long as you have
code to unwrap the migration

I've cc'd Michael Coates (our security guy) since he can provide more
background on why we're moving towards this strategy. Basically, if
people are using weak passwords, switching hashing schemes is not
going to provide much more protection. If it takes 0.3 seconds to
encrypt "pa$$word" then it took 0.3 seconds, but I still have your
user's password. We're trying to structure a system that provides more
entropy and prevents weak passwords altogether.

-- 
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: psycopg2.OperationalError: could not connect to server

2011-02-22 Thread Gabriel Hurley 
This list is for the development of Django itself. Please try asking your 
question on the Django Users list
.

All the best,

- Gabriel Hurley

-- 
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.

Django app framework to allow configuration of apps via admin interface

2011-02-22 Thread Nico 
Hi! I am working on a django site for simple class (as in teachers)
management. Because the people I am targeting for this site won't
necessarily have any python or other technical skills, I want to make
it so they can enable/disable user access to apps and configure apps
via the admin interface.

Does something like this already exist for django that you guys know
of? I have written up a working initial implementation that lets you
declare different kinds of options in an app and then work with those
options via the admin interface. I wonder, if something like this
doesn't exist yet, if it would be something others might be interested
in.

Thanks!
Nico

-- 
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.

Multiple email connections

2011-02-22 Thread Niran Babalola 
Multiple databases and caches can currently be configured in one's
settings file. It'd be nice if the same could be done with email
connections. For example, Amazon's SES starts out new users with a low
quota that they gradually increase, so splitting emails between SES
and other connections to start out with is a useful approach.

Has any work been done on this? A quick Google turns up nothing. I've
written code that does most of this, but I wanted to make sure it has
general appeal before getting it in shape for a proper patch.

- Niran

-- 
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: Django app framework to allow configuration of apps via admin interface

2011-02-22 Thread Karen Tracey 
Please direct questions/discussions about using Django to django-users. The
topic of this list is the development of core Django itself.

Karen

-- 
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: Multiple email connections

2011-02-22 Thread Russell Keith-Magee 
On Wed, Feb 23, 2011 at 9:02 AM, Niran Babalola  wrote:
> Multiple databases and caches can currently be configured in one's
> settings file. It'd be nice if the same could be done with email
> connections. For example, Amazon's SES starts out new users with a low
> quota that they gradually increase, so splitting emails between SES
> and other connections to start out with is a useful approach.
>
> Has any work been done on this? A quick Google turns up nothing. I've
> written code that does most of this, but I wanted to make sure it has
> general appeal before getting it in shape for a proper patch.

I'm not aware of any work that has been done in this area.

As you have noticed, we've been moving away from singletons where
possible; DATABASES in Django 1.2, CACHES in Django 1.3.
EMAIL_BACKENDS would be a logical next step. Most of the email APIs
are already configured to allow for multiple email servers; it's
really just a matter of changing the way that email settings are
parsed in get_connection().

So -- if you want to polish this up for a 1.4 feature, it could be an
easy 1.4 feature.

Yours,
Russ Magee %-)

-- 
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: Delete cascade up for Inherited models

2011-02-22 Thread Russell Keith-Magee 
On Mon, Feb 21, 2011 at 1:56 PM, Rahul  wrote:
> When i ran the test cases ( "modeltests/delete/
> test_inheritance_cascade_up" ) which were doing cascade up for
> inherited models, it failed for DB2 cause of the fact that DB2 doesn't
> support initial deferred constraint checks like behavior, hence it is
> must to execute delete statement from child to parent, however when I
> traced the sql execution for "modeltests/delete/
> test_inheritance_cascade_up" test case, what I find is Django tried to
> execute delete sql from parent to child. I already had the flag
> "can_defer_constraint_checks" set to false inside DatabaseFeatures.

To the best of my knowledge, that flag is only used for testing
purposes. It is used to identify tests that will be known to fail
because of required forward referenced foreign keys in test data. In
practice, the only officially supported database that is affected is
MySQL/InnoDB.

> Wondering if there a hook exists through which i can change the parent
> to child execution of sql to child to parent through our DB2 Django
> adaptor.

No, that hook doesn't exist -- because only because none of the other
databases have needed it.

As always, if you find yourself in a position where you need a hook or
other configuration item in order to support the features (or lack
thereof) of your third-party database backend, make a proposal.

Yours,
Russ Magee %-)

-- 
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: Delete cascade up for Inherited models

2011-02-22 Thread Alex Gaynor 
On Wed, Feb 23, 2011 at 1:37 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> On Mon, Feb 21, 2011 at 1:56 PM, Rahul 
> wrote:
> > When i ran the test cases ( "modeltests/delete/
> > test_inheritance_cascade_up" ) which were doing cascade up for
> > inherited models, it failed for DB2 cause of the fact that DB2 doesn't
> > support initial deferred constraint checks like behavior, hence it is
> > must to execute delete statement from child to parent, however when I
> > traced the sql execution for "modeltests/delete/
> > test_inheritance_cascade_up" test case, what I find is Django tried to
> > execute delete sql from parent to child. I already had the flag
> > "can_defer_constraint_checks" set to false inside DatabaseFeatures.
>
> To the best of my knowledge, that flag is only used for testing
> purposes. It is used to identify tests that will be known to fail
> because of required forward referenced foreign keys in test data. In
> practice, the only officially supported database that is affected is
> MySQL/InnoDB.
>
>
No it is used:
http://code.djangoproject.com/browser/django/trunk/django/db/models/deletion.py#L17


> > Wondering if there a hook exists through which i can change the parent
> > to child execution of sql to child to parent through our DB2 Django
> > adaptor.
>
> No, that hook doesn't exist -- because only because none of the other
> databases have needed it.
>
> As always, if you find yourself in a position where you need a hook or
> other configuration item in order to support the features (or lack
> thereof) of your third-party database backend, make a proposal.
>
> Yours,
> Russ Magee %-)
>
> --
> 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.
>
>
Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

-- 
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: render_to_* vs Template.render

2011-02-22 Thread Russell Keith-Magee 
On Tue, Feb 22, 2011 at 6:41 AM, Chris Beaven  wrote:
> After hunting down a very elusive bug, I found the cause to be due to the
> fact that render_to_string leaves the context in a different state than it
> started (due to the context stack being pushed before rendering, and then
> not popped).
> This behavior differs from a standard Template.render call and it seemed
> like a straight forward enough inconsistency so I committed [1] which
> changed render_to_string to leave the context how it found it.
> Being an idiot, I did my full test-suite pass against the wrong branch and
> therefore failed to heed some warning bells of the impact of this  :(
> I've since fixed the test-suite failures [2] (there's still one outstanding
> issue [3] although that has an easy enough solution).
>
> Anyway, the change in [1] is backwards incompatible, due to the fact that
> people may be relying on the render_to_string (or render_to_response which
> uses this method) method leaving the context stack 'unresolved'.

Bugs have never been considered as part of our backwards compatibility
policy. To me, this falls clearly in the category of "bug". I can't
think of any reason why render_to_string() would be expected to be
context modifying.

So, Option B (keep the change but document it in release notes) seems
right to me.

On a related note -- I noticed that our "bugs aren't covered" angle
isn't actually mentioned as an exception to API stability. That should
probably be rectified.

Yours,
Russ Magee %-)

-- 
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: Delete cascade up for Inherited models

2011-02-22 Thread Russell Keith-Magee 
On Wed, Feb 23, 2011 at 2:39 PM, Alex Gaynor  wrote:
>
>
> On Wed, Feb 23, 2011 at 1:37 AM, Russell Keith-Magee
>  wrote:
>>
>> On Mon, Feb 21, 2011 at 1:56 PM, Rahul 
>> wrote:
>> > When i ran the test cases ( "modeltests/delete/
>> > test_inheritance_cascade_up" ) which were doing cascade up for
>> > inherited models, it failed for DB2 cause of the fact that DB2 doesn't
>> > support initial deferred constraint checks like behavior, hence it is
>> > must to execute delete statement from child to parent, however when I
>> > traced the sql execution for "modeltests/delete/
>> > test_inheritance_cascade_up" test case, what I find is Django tried to
>> > execute delete sql from parent to child. I already had the flag
>> > "can_defer_constraint_checks" set to false inside DatabaseFeatures.
>>
>> To the best of my knowledge, that flag is only used for testing
>> purposes. It is used to identify tests that will be known to fail
>> because of required forward referenced foreign keys in test data. In
>> practice, the only officially supported database that is affected is
>> MySQL/InnoDB.
>>
>
> No it is used:
> http://code.djangoproject.com/browser/django/trunk/django/db/models/deletion.py#L17

That sound you heard was my facepalm as I remembered something that I
should have remembered without prompting. :-)

Yours,
Russ Magee %-)

-- 
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: Suggestion: a new "nature" field in Trac

2011-02-22 Thread Russell Keith-Magee 
On Tue, Feb 22, 2011 at 10:36 PM, Daniel Moisset
 wrote:
> On Tue, Feb 22, 2011 at 11:21 AM, Russell Keith-Magee
>  wrote:
>>
>> This is one of those areas where we need someone to step up an
>> volunteer to do some Trac work and show us what is possible.
>>
>
> If http://trac-hacks.org/wiki/VotePlugin is fine for the needs, I'm ok
> with helping install it; although I need proper access to install it
> in the django trac.
>
> Same offer re #14702, given that I was the one pushing for it :)

Looks promising. I'll start poking people and see what we have to do
to get this installed; if we need warm bodies to make the change
happen, I'll let you know.

Yours,
Russ Magee %-)

-- 
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: Suggestion: a new "nature" field in Trac

2011-02-22 Thread Russell Keith-Magee 
On Wed, Feb 23, 2011 at 2:53 AM, Julien Phalip  wrote:
> On Feb 22, 3:22 am, Russell Keith-Magee 
> wrote:
>> Like I have said many times in the past -- issuing queries to find
>> tickets needing review isn't a problem we have. The information that
>> is needed is all there. What we *do* have are two other problems:
>>
>>  1) Finding people willing to be altruistic and review someone else's
>> work, rather than their own
>>  2) Directing people who are inclined to be altruistic to the right place.
>>
>> I know that UX can affect engagement, so it's entirely possible that
>> the whole Trac process is an impediment to engagement of potential
>> reviewers. However, I strongly challenge the assertion that either of
>> these problems can be fixed by simply adding a triage states alone. A
>> triage state just changes the query (arguably simplifying it) -- it
>> doesn't by itself increase the number of people volunteering.
>>
>> The problem we have is a much deeper problem of community engagement.
>> Unfortunately, this is also problem that I don't have any magic
>> solutions for. Convincing people to be altruistic is hard.
>>
>> A triage state also doesn't help people who *are* inclined to help to
>> actually find the information that would allow them to help. That
>> means the contribution guide, and the Trac reports page. Hopefully,
>> #14401 will address this somewhat. Either way, I don't think a Trac
>> flag will help -- it's a more fundamental IA problem for the project
>> itself (i.e., how to direct people to the right information).
>>
>> One Trac feature that I suspect *might* help in this regard is one
>> that I've raised before -- allowing users to flag individual issues
>> that they have an interest in seeing solved. This isn't just another
>> flag, because it provides a way to slice and present the data in a
>> different way. It would allow us to provide a project-wide leaderboard
>> of the "most wanted bugs", providing a focus for volunteer activity
>> that doesn't currently exist. However, this requires someone to spend
>> time developing that feature for Trac, because it isn't (to my
>> knowledge) an out-of-the-box feature.
>
> I'm voting +1 for the voting feature suggested by Daniel in his
> previous reply to this thread.
>
> As far increasing community engagement is concerned, off the top of my
> head there are at least three things worth exploring:
>
> 1) Advertise
>
> For example:
>
> * The reports page is useful but it's easily missed. Perhaps there
> should be a reminder and a link to it in every future sprint
> announcements.
> * There should be a huge "Contribute to Django" button (with round
> cornerz) on the djangoproject.com homepage linking to more info (e.g.
> to the page that Gabriel has been drafting recently).
> * I believe the vast majority of django users come to the
> djangoproject.com website primarily to view the documentation. So a
> hard-to-miss "Contribute to Django" link could be displayed on every
> single page of the doc.

Agreed that the Django homepage needs some work, and this is one of
the things that needs to be addressed. In fact, I seem to recall
talking to someone about this exact problem... :-P

> 2) Make the barrier for contribution seem lower.
>
> Gabriel has already done an awesome job with the new "Contribute to
> Django" page in the doc. The reports page is also great but could be
> improved with more query links and more descriptive scenarios
> explaining what types of contribution could be done based on one's
> programming abilities, or on one's familiarity with Django's
> internals, or on one's mood, or on one's available time, etc. It
> should be emphasised that there are lots of quick and easy ways to
> contribute meaningfully.

Agreed that this is an area where we could improve. Suggestions and
patches welcome.

> 3) Make contributing enticing
>
> The two points above combined would probably themselves increase
> entice-ability but clearly that wouldn't be enough. Some common
> catalysers for user participation based on peer recognition are: user
> rankings (automatically based on the number of comments, for example)
> or users voting for other users (like it's done for example at
> ted.com). I'm not sure how hard that type of things would be to
> implement in Trac though, or if some plugins already exist.

The risk here is turning the process into something that can be gamed,
which means you end up having people playing the game -- and, since
we're dealing with hackers, looking for ways to beat the game --
rather than actually contributing in a useful way. If we introduce
game mechanics, we have to be careful that those mechanics don't
undermine or distract from our actual goals.

However, I'm not completely opposed the introduction of game-like
mechanics, subject to a someone making a concrete proposal that will
meet this criterion.

This is something that could be tied into a revised djangopeople.org
(e.g, get your "opened a ticket" badge, or your "

Re: Suggestion: a new "nature" field in Trac

2011-02-22 Thread Łukasz Rekucki 
> or an invitation to a 'high value contributors' party at
> DjangoCon.

Uuu... would I get a hoove shake from Django's Magical Pony ? ;-)

Anyways, I'm +1 on adding a "nature" field to track - It would've been
very helpful right before feature-freeze (so I can weed out simple
features that lingered for too long) and right after it (so that
bumping is easier).

-- 
Łukasz Rekucki

-- 
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.