Introduction to GSOC 2014

[Vinay Raghavan]

Hi, I'm Vinay Raghavan. I'm a self- taught programmer and currently 
pursuing BE. in Electronics and Communication.

I am interested in working on the project "Test framework cleanup".
I have about 5 months experience of developing information mining web 
applications using Django during my internship. Information mining happens 
to be one of my favorite fields.


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0886dc84-9046-4e46-9fd9-448b3a0a8541%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

What do you need for crowdfunding Django?

[olivermarchand]

Dear Django developer,

A lot of you invest their personal time for shaping Django. That's great! 
But at the end of the day you all have to buy bread, pay rent and need new 
laptops... www.100-days.net  is a crowd-sourcing 
platform that wants to help the open source movement and asks for your 
input on how to best help you get all your projects properly funded. Many 
of you have seen the success story of  Andrew Godwin in funding schema 
migrations for Django. The projects was funded in an hour and 5 minutes and 
raised 
a total of 17K £ instead of 2.5K £. (
https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django
) We think that this is a new "social net economy" developing and we want 
to help shaping it.

Here are our questions:

* Have you ever considered funding your project through a crowd
sourcing platform? Why yes, why no?

* What would it take for you to register a project?

* Which features would you love to see on 100-days for developers
(github integration, project management, specification tools, ...)?

thanks for your help,
Oliver

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/41833af6-e575-46ca-9058-0b2d2611a178%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

requiring login to perform Trac actions?

[Tim Graham]

There's been some discussion on ticket 
#22067 and 
#django-dev about requiring Trac login to help cut down on spam and 
generally improve the quality of the discussion.

Claude:  I think that forcing registration would be fine. It adds a small 
barrier to reporting bugs, but I think it's acceptable, and many projects 
have already chosen to do so.

me: I'm in favor of requiring registration as well. When I posed this on 
IRC, Aymeric mentioned: "BDFLs were very attached to the ability to report 
issues without creating an account." On the other hand, we've seen 
anonymously reported issues where we respond and don't know if the reporter 
will ever respond since they won't be notified of our response. There also 
a fair number of comments and other changes that are accidentally made 
anonymously which results in some extra noise.

If you believe the "create an account" barrier is a problem, do you think 
adding something like GitHub auth to Trac would lower the barrier to an 
acceptable level?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f7b8bc59-4018-4731-aa61-34a5b2341d5a%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: requiring login to perform Trac actions?

[anubhav joshi]

>
> If you believe the "create an account" barrier is a problem, do you think 
> adding something like GitHub auth to Trac would lower the barrier to an 
> acceptable level?
>

 I am in favour of this, as while I was going through tickets, I have found 
many tickets where people have anonymously posted replies and never 
replied.

Regards,
Anubhav Joshi

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5510e93c-95f2-4bfe-bec6-2d963a6f6bd8%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: The model API and strong typing

[Piper Merriam]

On Saturday, March 1, 2014 4:29:43 PM UTC-7, Russell Keith-Magee wrote:
>
>
> On Sun, Mar 2, 2014 at 1:07 AM, Aymeric Augustin <
> aymeric@polytechnique.org > wrote:
>
>> On 1 mars 2014, at 09:14, Martin Matusiak > 
>> wrote:
>>
>> A structural reason is that you can't tell "assigning an attribute to an
>> instance in order to save it to the database later" apart from "assigning 
>> an
>> attribute to an instance being loaded from the database". So your proposal
>> doesn't play nice with lazy loading of related instances, for example.
>>
>> Another reason is the impossibility of running validations involving 
>> multiple
>> fields. If a validator depends on the value of two fields, one has to be 
>> set
>> before the other, and you can't validate at that point.
>>
>
> For me, this is the bigger reason why validation at time of assignment 
> isn't viable. 
>
> In order to do multi-field validation at time of assignment, we'd need to 
> introduce some sort of transactional behaviour. Just thinking about this 
> makes my brain hurt.
>
>  
Russ

This got me thinking about what the API for doing multi-field validation 
could look like.  I came up with two ideas that may or may not hold water.

The simplest solution I could think of would be a setter method on the 
model that took **kwargs and set them on the model, calling validation 
after they've all been set.  Kind of a gross API, but it should work.

The maybe cleaner idea would be a context manager that deferred validation 
till the end of the context block.

with instance.validation_block():
x = 4
y = 5


Here's a gist that hopefully demonstrates the idea. 
 https://gist.github.com/pipermerriam/e858cd6f2c2535d8868d
 
I'm +0 on this idea overall, but I think it'd be nice to have a better 
system for model validation than the current state of things.  I'm just not 
sure what that looks like.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/005f59d8-ce61-4d1c-bdbd-07efbe9bc388%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

my admin theme

[adam spence]

Hi guys,

I was wondering what you thought of my proposal to contribute my bootstrap
admin theme?

It doesn't make sense to not allow Django admin to be pretty and extendable
out of the box does it? I do understand however that the admin is intended
for a developer audience. I am always rapidly prototyping systems for
clients and the admin always ends up being used by non-technical
colleagues, which in turn means I (being more of a UI dev) get loads of
complaints over how hard it is to use once you flesh it out. The widgets
could do with being easier to re-skin with custom templates IMO.

I'd be honoured if you'd let me get this into Django itself. Please let me
know if you would consider this, otherwise I can just make a module. I'm
going to rebuild my current django-admintools-bootstrap module and remove
many of the dependencies.
https://github.com/spenoir/django-admintools-bootstrap#todo

BTW, I've had quite a few people star it so perhaps the community want it?

all the best,

adam

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEWLFEH0NA0Mp%3D0uwryNfSfYKYyFkWx8HM16twc5vpRyRJPdZg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: my admin theme

[Curtis Maloney]

Was just looking at your site... and it looks slick (love admin-tools
Menus), but some of the deps worry me.  BeautifulSoup?

ADMINTOOLS_BOOTSTRAP_SITE_LINK = '/'

Why is this special?  Why doesn't it use staticfiles like everything else?

IMHO the problems with admin go much deeper than the markup/styling... but
I've not had time yet to dig in properly.

--
C


On 4 March 2014 09:35, adam spence  wrote:

> Hi guys,
>
> I was wondering what you thought of my proposal to contribute my bootstrap
> admin theme?
>
> It doesn't make sense to not allow Django admin to be pretty and
> extendable out of the box does it? I do understand however that the admin
> is intended for a developer audience. I am always rapidly prototyping
> systems for clients and the admin always ends up being used by
> non-technical colleagues, which in turn means I (being more of a UI dev)
> get loads of complaints over how hard it is to use once you flesh it out.
> The widgets could do with being easier to re-skin with custom templates
> IMO.
>
> I'd be honoured if you'd let me get this into Django itself. Please let me
> know if you would consider this, otherwise I can just make a module. I'm
> going to rebuild my current django-admintools-bootstrap module and remove
> many of the dependencies.
> https://github.com/spenoir/django-admintools-bootstrap#todo
>
> BTW, I've had quite a few people star it so perhaps the community want it?
>
> all the best,
>
> adam
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAEWLFEH0NA0Mp%3D0uwryNfSfYKYyFkWx8HM16twc5vpRyRJPdZg%40mail.gmail.com
> .
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSDB-icT05yMCdsSAfmkvs8oCNbLyrr%2BL6UMcevePs9wog%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: requiring login to perform Trac actions?

[Russell Keith-Magee]

On Mon, Mar 3, 2014 at 10:17 PM, Tim Graham  wrote:

> There's been some discussion on ticket 
> #22067 and
> #django-dev about requiring Trac login to help cut down on spam and
> generally improve the quality of the discussion.
>
> Claude:  I think that forcing registration would be fine. It adds a small
> barrier to reporting bugs, but I think it's acceptable, and many projects
> have already chosen to do so.
>
> me: I'm in favor of requiring registration as well. When I posed this on
> IRC, Aymeric mentioned: "BDFLs were very attached to the ability to report
> issues without creating an account." On the other hand, we've seen
> anonymously reported issues where we respond and don't know if the reporter
> will ever respond since they won't be notified of our response. There also
> a fair number of comments and other changes that are accidentally made
> anonymously which results in some extra noise.
>

I completely agree that the spam is well out of control, and we need to do
*something*.

Providing the historical perspective (get off my lawn, you kids! :-) - we
didn't enforce registration because we wanted to make sure the barrier to
contribution was as low as possible. If someone finds a bug and they work
up the courage to lodge a ticket, they don't care about our process - they
just want to contribute. Every hoop we make them jump through is one more
chance that they'll walk away without providing their feedback. And the
feedback of people who are brand new to the project is often the most
valuable, because it shows you where the cognitive dissonance lies in your
tutorial and documentation.

This was especially true in the early days, when we weren't a huge project.
In those days, every new contributor was gold, and to that end, *any* bug
report was worthwhile. On top of that, in the early days the bugs that did
exist were obvious enough that with a bit of a poke in the general
direction, someone else could probably triage them.

This decision was then reinforced by the number of people who had problems
with the Trac login process. I don't know if it's because we've got it
configured wrong, or if it's just inherently bad (it's been over 8 years
since I created my account, so I don't remember my initial experience), but
there's been a constant undercurrent of "My trac signup didn't work"
messages on django-dev for as long as I can remember.

Of course, new contributors are still gold, and we shouldn't do anything
that will discourage contributions, but we have a little more momentum now.


> If you believe the "create an account" barrier is a problem, do you think
> adding something like GitHub auth to Trac would lower the barrier to an
> acceptable level?
>

This sounds like a reasonable option to me. Any halfway serious potential
contributor should have a Github account, and it matches Django's own
toolchain. The oAuth process is pretty smooth, so the problem set is down
to "users who are genuinely new to software".

The only other option I can think of would be to do the same thing that we
do with Google Groups - the first post for each contributor is held for
moderation. Of course, in the Google Groups case, every user is already
logged in...

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq848cSSyOMUh21XEQ%3DkwcdLyCQ9nDYPw40mWiHB7J%3DsLZ%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: The model API and strong typing

[Russell Keith-Magee]

On Tue, Mar 4, 2014 at 4:46 AM, Piper Merriam wrote:

>
>
> On Saturday, March 1, 2014 4:29:43 PM UTC-7, Russell Keith-Magee wrote:
>>
>>
>> On Sun, Mar 2, 2014 at 1:07 AM, Aymeric Augustin > polytechnique.org> wrote:
>>
>> On 1 mars 2014, at 09:14, Martin Matusiak  wrote:
>>>
>>> A structural reason is that you can't tell "assigning an attribute to an
>>> instance in order to save it to the database later" apart from
>>> "assigning an
>>> attribute to an instance being loaded from the database". So your
>>> proposal
>>> doesn't play nice with lazy loading of related instances, for example.
>>>
>>> Another reason is the impossibility of running validations involving
>>> multiple
>>> fields. If a validator depends on the value of two fields, one has to be
>>> set
>>> before the other, and you can't validate at that point.
>>>
>>
>> For me, this is the bigger reason why validation at time of assignment
>> isn't viable.
>>
>> In order to do multi-field validation at time of assignment, we'd need to
>> introduce some sort of transactional behaviour. Just thinking about this
>> makes my brain hurt.
>>
>>
> Russ
>
> This got me thinking about what the API for doing multi-field validation
> could look like.  I came up with two ideas that may or may not hold water.
>
> The simplest solution I could think of would be a setter method on the
> model that took **kwargs and set them on the model, calling validation
> after they've all been set.  Kind of a gross API, but it should work.
>

So, for the low low price of preventing you from using = for assignment,
you get data validation!

Not sure I see this as an improvement :-)


> The maybe cleaner idea would be a context manager that deferred validation
> till the end of the context block.
>
> with instance.validation_block():
> x = 4
> y = 5
>
>
Yes - like I said, transactional behaviour. And it makes my brain hurt
thinking about it :-)

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq84-KT6eY2bh0dpFVmhAfGpudYj1Jh27CAiDg0Q8avka51Q%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: my admin theme

[Florian Apolloner]

Hi,

On Monday, March 3, 2014 11:35:31 PM UTC+1, adam spence wrote:
>
> I was wondering what you thought of my proposal to contribute my bootstrap 
> admin theme?
>
If you are refering to 
https://groups.google.com/d/msg/django-developers/0fD9zGtOhMg/vAdAOvxikFAJ 
-- you already got the answer of one core dev, that bootstrap is most 
likely not going to fly. Given that there are no other responses from core 
devs, you can assume that at least some of us feel the same way. Personally 
I find your grey-in-grey theme visually less appealing than the current 
admin.
 

> It doesn't make sense to not allow Django admin to be pretty and 
> extendable out of the box does it?
>
My personal experience is that it's way easier to extend zurb foundation 
than bootstrap, bootstrap is already very opinionated; so if we'd use a CSS 
framework bootstrap would at least get -0 from me if not even -1.
 

> BTW, I've had quite a few people star it so perhaps the community want it?
>
Please don't get me wrong, but github starring is used somewhat 
inflationary and 50 stars don't exactly represent the community.

Regards,
Florian 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7fc57b3b-b070-4b84-a8c6-8261c710a718%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: What do you need for crowdfunding Django?

[Russell Keith-Magee]

On Mon, Mar 3, 2014 at 8:56 PM, olivermarchand wrote:

> Dear Django developer,
>
> A lot of you invest their personal time for shaping Django. That's great!
> But at the end of the day you all have to buy bread, pay rent and need
> new laptops... www.100-days.net  is a crowd-sourcing
> platform that wants to help the open source movement and asks for your
> input on how to best help you get all your projects properly funded. Many
> of you have seen the success story of  Andrew Godwin in funding schema
> migrations for Django. The projects was funded in an hour and 5 minutes
> and raised a total of 17K £ instead of 2.5K £. (
> https://www.kickstarter.com/projects/andrewgodwin/schema-
> migrations-for-django) We think that this is a new "social net economy"
> developing and we want to help shaping it.
>
> Here are our questions:
>
> * Have you ever considered funding your project through a crowd
> sourcing platform? Why yes, why no?
>
> * What would it take for you to register a project?
>
> * Which features would you love to see on 100-days for developers
> (github integration, project management, specification tools, ...)?
>
>
Hi Oliver,

I'm sorry, but to me, this post is borderline spam.

I can appreciate that you are enthused about your project and believe that
there may be utility for the Django project, but it isn't at all clear to
me what that utility *is*, or how what you're proposing is in any way
different from what we're already doing (successfully) with Kickstarter.

And, as I've told a number of other crowd funding platforms that have
approached the project and the DSF, there is a lot of devil in the details
when crowdsourcing and Open Source interact. The simplest version of this
problem: If one person reports a bug, another person triages the ticket, a
third writes a patch, a fourth writes the tests, a fifth reviews the patch,
and a core team member commits, that's 6 people involved in a relatively
simple bug fix. How do funds get distributed between the 6?

The two projects that Django has crowd funded have been very specifically
chosen -- very clear feature sets, for features to be developed and
committed by a member of the core team. This doesn't easily scale to the
broader community.

Have you got a specific proposal for the Django project? If so, I'm
certainly interested in hearing it - but it needs to be specific. If not,
please refrain from posting to django-developers - this is a forum for
discussing the development of Django, not an advertising platform.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq8489yrQpBpwSAVviFamcAM4of3CuCPh2JdCu9QjmQGzx6Q%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: requiring login to perform Trac actions?

[Marc Tamlyn]

+1 to github oauth and requiring login. Having github auth, especially for
new reports is very useful and would help to tie together when people use
different names.

Marc
On 3 Mar 2014 23:44, "Russell Keith-Magee"  wrote:

>
> On Mon, Mar 3, 2014 at 10:17 PM, Tim Graham  wrote:
>
>> There's been some discussion on ticket 
>> #22067 and
>> #django-dev about requiring Trac login to help cut down on spam and
>> generally improve the quality of the discussion.
>>
>> Claude:  I think that forcing registration would be fine. It adds a small
>> barrier to reporting bugs, but I think it's acceptable, and many projects
>> have already chosen to do so.
>>
>> me: I'm in favor of requiring registration as well. When I posed this on
>> IRC, Aymeric mentioned: "BDFLs were very attached to the ability to report
>> issues without creating an account." On the other hand, we've seen
>> anonymously reported issues where we respond and don't know if the reporter
>> will ever respond since they won't be notified of our response. There also
>> a fair number of comments and other changes that are accidentally made
>> anonymously which results in some extra noise.
>>
>
> I completely agree that the spam is well out of control, and we need to do
> *something*.
>
> Providing the historical perspective (get off my lawn, you kids! :-) - we
> didn't enforce registration because we wanted to make sure the barrier to
> contribution was as low as possible. If someone finds a bug and they work
> up the courage to lodge a ticket, they don't care about our process - they
> just want to contribute. Every hoop we make them jump through is one more
> chance that they'll walk away without providing their feedback. And the
> feedback of people who are brand new to the project is often the most
> valuable, because it shows you where the cognitive dissonance lies in your
> tutorial and documentation.
>
> This was especially true in the early days, when we weren't a huge
> project. In those days, every new contributor was gold, and to that end,
> *any* bug report was worthwhile. On top of that, in the early days the bugs
> that did exist were obvious enough that with a bit of a poke in the general
> direction, someone else could probably triage them.
>
> This decision was then reinforced by the number of people who had problems
> with the Trac login process. I don't know if it's because we've got it
> configured wrong, or if it's just inherently bad (it's been over 8 years
> since I created my account, so I don't remember my initial experience), but
> there's been a constant undercurrent of "My trac signup didn't work"
> messages on django-dev for as long as I can remember.
>
> Of course, new contributors are still gold, and we shouldn't do anything
> that will discourage contributions, but we have a little more momentum now.
>
>
>> If you believe the "create an account" barrier is a problem, do you think
>> adding something like GitHub auth to Trac would lower the barrier to an
>> acceptable level?
>>
>
> This sounds like a reasonable option to me. Any halfway serious potential
> contributor should have a Github account, and it matches Django's own
> toolchain. The oAuth process is pretty smooth, so the problem set is down
> to "users who are genuinely new to software".
>
> The only other option I can think of would be to do the same thing that we
> do with Google Groups - the first post for each contributor is held for
> moderation. Of course, in the Google Groups case, every user is already
> logged in...
>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJxq848cSSyOMUh21XEQ%3DkwcdLyCQ9nDYPw40mWiHB7J%3DsLZ%2Bw%40mail.gmail.com
> .
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1H9pRBx57Oq-zEEXvKoSEita8CpqDsfaWkounX1VMbC9g%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: requiring login to perform Trac actions?

[Anssi Kääriäinen]

I'd like to have some security against reporting as somebody else. 
Currently one can report or comment anonymously and mark reporter as 
core committer. This is too easy to abuse. +1 for requiring login. At 
least force anonymous reports to be anonymous.


 - Anssi

On 03/04/2014 09:24 AM, Marc Tamlyn wrote:


+1 to github oauth and requiring login. Having github auth, especially 
for new reports is very useful and would help to tie together when 
people use different names.


Marc

On 3 Mar 2014 23:44, "Russell Keith-Magee" > wrote:



On Mon, Mar 3, 2014 at 10:17 PM, Tim Graham mailto:timogra...@gmail.com>> wrote:

There's been some discussion on ticket #22067
 and #django-dev
about requiring Trac login to help cut down on spam and
generally improve the quality of the discussion.

Claude:  I think that forcing registration would be fine. It
adds a small barrier to reporting bugs, but I think it's
acceptable, and many projects have already chosen to do so.

me: I'm in favor of requiring registration as well. When I
posed this on IRC, Aymeric mentioned: "BDFLs were very
attached to the ability to report issues without creating an
account." On the other hand, we've seen anonymously reported
issues where we respond and don't know if the reporter will
ever respond since they won't be notified of our response.
There also a fair number of comments and other changes that
are accidentally made anonymously which results in some extra
noise.


I completely agree that the spam is well out of control, and we
need to do *something*.

Providing the historical perspective (get off my lawn, you kids!
:-) - we didn't enforce registration because we wanted to make
sure the barrier to contribution was as low as possible. If
someone finds a bug and they work up the courage to lodge a
ticket, they don't care about our process - they just want to
contribute. Every hoop we make them jump through is one more
chance that they'll walk away without providing their feedback.
And the feedback of people who are brand new to the project is
often the most valuable, because it shows you where the cognitive
dissonance lies in your tutorial and documentation.

This was especially true in the early days, when we weren't a huge
project. In those days, every new contributor was gold, and to
that end, *any* bug report was worthwhile. On top of that, in the
early days the bugs that did exist were obvious enough that with a
bit of a poke in the general direction, someone else could
probably triage them.

This decision was then reinforced by the number of people who had
problems with the Trac login process. I don't know if it's because
we've got it configured wrong, or if it's just inherently bad
(it's been over 8 years since I created my account, so I don't
remember my initial experience), but there's been a constant
undercurrent of "My trac signup didn't work" messages on
django-dev for as long as I can remember.

Of course, new contributors are still gold, and we shouldn't do
anything that will discourage contributions, but we have a little
more momentum now.

If you believe the "create an account" barrier is a problem,
do you think adding something like GitHub auth to Trac would
lower the barrier to an acceptable level?


This sounds like a reasonable option to me. Any halfway serious
potential contributor should have a Github account, and it matches
Django's own toolchain. The oAuth process is pretty smooth, so the
problem set is down to "users who are genuinely new to software".

The only other option I can think of would be to do the same thing
that we do with Google Groups - the first post for each
contributor is held for moderation. Of course, in the Google
Groups case, every user is already logged in...

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.
To view this discussion on the web visit

https://groups.google.com/d/msgid/django-developers/CAJxq848cSSyOMUh21XEQ%3DkwcdLyCQ9nDYPw40mWiHB7J%3DsLZ%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

Re: requiring login to perform Trac actions?

[Sam Lai]

On 4 March 2014 10:44, Russell Keith-Magee  wrote:
>> If you believe the "create an account" barrier is a problem, do you think
>> adding something like GitHub auth to Trac would lower the barrier to an
>> acceptable level?
>
>
> This sounds like a reasonable option to me. Any halfway serious potential
> contributor should have a Github account, and it matches Django's own
> toolchain. The oAuth process is pretty smooth, so the problem set is down to
> "users who are genuinely new to software".

I've worked in a few industries where developers have never heard of
git, even if they spend their whole day on a Linux box and are
definitely not 'new to software'. That said, it is possible that the
subset who use Django are probably likely to be familiar with GitHub
given that Django is a web framework. Maybe some explanatory text at
the login screen would mitigate the issue.

Also, will GitHub oAuth actually solve the sporadic login issues?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABxbXqU9PmCdp%3D4EOZoEJD4C4SP5j45srhGoxJfR2ZRqe0HtLQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.