Re: Default upload permissions

[Ira Abbott]

I like this solution, as it applies the fix for new things moving forward 
with no change in 
behavior to cause problem for existing tweaked in sites.  The most likely
time to run in to this problem is, in my opinion, is when varying platforms 
or starting fresh
projects.  Once settled in to a project/platform combination, minor OS and 
platform feature 
patches, etc. are are unlikely to change behavior.  


On Friday, December 7, 2018 at 11:04:21 AM UTC-5, René Fleschenberg wrote:
>
> Hi, 
>
> On 12/5/18 9:54 AM, Carlton Gibson wrote: 
> > *Proposal*: we should change the default for FILE_UPLOAD_PERMISSION to 
> > 0o644 (or maybe 0o664), and document that as a backward incompatible 
> > change. This would be correct for almost all users.  If you're 
> > deliberately leveraging `FILE_UPLOAD_PERMISSION = None` it's an easy 
> > switch back to the current behaviour. 
> As someone who wasted a couple of hours because of the current behavior, 
> I am very much in favor of this. 
>
> The second-best solution in my opinion would be to have ``manage.py 
> startproject`` explicitly write the setting, either as 0o644 or as 0o600. 
>
> -- 
> René Fleschenberg 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a8ea6c6b-b04c-4160-b707-dfccd816526c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Ira Abbott]

Apologies for the double post - my last one was not clear.  "just that" 
means that the payment is intended to indicate that it is worth a JIRA 
license to me to not use JIRA.

This group does great things.  I am sure that the group can come up with 
some interesting ways to scale that will ultimately benefit the framework 
as a whole.

On Monday, December 10, 2018 at 3:21:53 PM UTC-5, Ira Abbott wrote:
>
> FWIW: Please consider my contribution of $84 (one bulk JIRA license for 
> one year) to be just that.
>
> On Monday, December 10, 2018 at 2:14:07 PM UTC-5, Zachary Garwood wrote:
>>
>> I'd pay money to NOT use Jira.
>>
>> On Mon, Dec 10, 2018, 11:09 AM Dan Davis >
>>> Tom, you are right about the UX issues, but full-text and inverted 
>>> indexing would help with the responsiveness as well.  Technically, I was 
>>> talking about djangoproject's TracSearch 
>>> .  That's closer to good UX as 
>>> well, because you can get there by progressive enhancement rather than 
>>> taking stuff away.
>>>
>>> You are also right that switching to another system such as github 
>>> issues could be a better fix than customizing Trac.   But I find it 
>>> difficult to believe that Github issues grows up to cover as much workflow 
>>> management as Trac issues or JIRA.   Maybe we need money to get JIRA.
>>>
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/CAFzonYZ%3DwRCX3HpfYCj0G2i3UrcQmVCDj%3Da%2BOb7zeqtvQm-pxg%40mail.gmail.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7dad5740-60a2-4cfc-a1be-b913c318ff48%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Ira Abbott]

FWIW: Please consider my contribution of $84 (one bulk JIRA license for one 
year) to be just that.

On Monday, December 10, 2018 at 2:14:07 PM UTC-5, Zachary Garwood wrote:
>
> I'd pay money to NOT use Jira.
>
> On Mon, Dec 10, 2018, 11:09 AM Dan Davis  
> wrote:
>
>> Tom, you are right about the UX issues, but full-text and inverted 
>> indexing would help with the responsiveness as well.  Technically, I was 
>> talking about djangoproject's TracSearch 
>> .  That's closer to good UX as 
>> well, because you can get there by progressive enhancement rather than 
>> taking stuff away.
>>
>> You are also right that switching to another system such as github issues 
>> could be a better fix than customizing Trac.   But I find it difficult to 
>> believe that Github issues grows up to cover as much workflow management as 
>> Trac issues or JIRA.   Maybe we need money to get JIRA.
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CAFzonYZ%3DwRCX3HpfYCj0G2i3UrcQmVCDj%3Da%2BOb7zeqtvQm-pxg%40mail.gmail.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0ff6066a-6425-40a2-8e15-74fd98e2f440%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Ira Abbott]

This project probably qualifies here:

https://www.atlassian.com/software/views/open-source-license-request


On Monday, December 10, 2018 at 2:05:40 PM UTC-5, Ira Abbott wrote:
>
> Hi,
>
> Just in case that JIRA crack was NOT sarcasm ...
>
> https://www.atlassian.com/software/jira/pricing  How many users would be 
> needed?  If going this way, I smell the need for a gateway / JIRA backend 
> for the community site and small number of actual JIRA users with the 
> creation coming from a single user with some sort of 'community-user' data 
> field patched in.  JIRA is certainly flexible and configurable this way and 
> capable of interface to other enterprise apps.  We would have to find out 
> how to make this work within their terms of service ...
>
> Otherwise, its probably "BYOL" for contributors at about <$7 / month.  
> i.e. possibly "$7/month for each month active", though I think they will 
> change for a constant number, which means managing floaters.  While new to 
> this community, I suspect that any other arrangement than these two is 
> prohibitive.  And even managing floaters for anyone not locked in by 
> commitment (contract) to the group adds risk to the group from the whatever 
> commitment exists with Atlassian for any fixed number.  This could 
> potentially bankrupt the group if not managed correctly.
>
> My other advice is to "KISS" when using JIRA.  All that configuration can 
> lead to a tendency for organizations to attempt to solve all of their 
> problems building workflows there.  This is VERY STICKY, hence the behemoth 
> that Atlassian has become and will continue to be for some time in to the 
> future.
>
> Finally, any major changes such as this are like an a manufacturing 
> organization changing ERP packages (been through several of those) - they 
> NEVER GO WELL, and inevitably, when the smoke clears users will long for 
> the old system despite its glaring deficiencies.
>
> I therefore will hold that improvements should be made to Trac in an 
> incremental Agile fashion rather than any conversion requiring a waterfall 
> rollout.  This is the part where Trac should be STICKY for the group, or 
> this will be disruptive.
>
> And besides, I like Python in general and don't to fall victim to 'pay to 
> play' to Atlassian / Oracle to develop open source software that, believe 
> me, refers everything Python as 'a bunch of scripts'.  I get enough of that 
> at work which is part of why I am here.
>
> Regards,
>
> Ira
>
> On Monday, December 10, 2018 at 12:10:05 PM UTC-5, Dan Davis wrote:
>>
>> Tom, you are right about the UX issues, but full-text and inverted 
>> indexing would help with the responsiveness as well.  Technically, I was 
>> talking about djangoproject's TracSearch 
>> .  That's closer to good UX as 
>> well, because you can get there by progressive enhancement rather than 
>> taking stuff away.
>>
>> You are also right that switching to another system such as github issues 
>> could be a better fix than customizing Trac.   But I find it difficult to 
>> believe that Github issues grows up to cover as much workflow management as 
>> Trac issues or JIRA.   Maybe we need money to get JIRA.
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a3427014-90ef-4219-9a11-7d7ba86547f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Zach Garwood]

I'd pay money to NOT use Jira.

On Mon, Dec 10, 2018, 11:09 AM Dan Davis  Tom, you are right about the UX issues, but full-text and inverted
> indexing would help with the responsiveness as well.  Technically, I was
> talking about djangoproject's TracSearch
> .  That's closer to good UX as
> well, because you can get there by progressive enhancement rather than
> taking stuff away.
>
> You are also right that switching to another system such as github issues
> could be a better fix than customizing Trac.   But I find it difficult to
> believe that Github issues grows up to cover as much workflow management as
> Trac issues or JIRA.   Maybe we need money to get JIRA.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAFzonYZ%3DwRCX3HpfYCj0G2i3UrcQmVCDj%3Da%2BOb7zeqtvQm-pxg%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAA-b4CjD0WY0fy2_QVoMkRGzZKAi%3DUE%3DA6N7oR0u-WECoKoJkQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Ira Abbott]

Hi,

Just in case that JIRA crack was NOT sarcasm ...

https://www.atlassian.com/software/jira/pricing  How many users would be 
needed?  If going this way, I smell the need for a gateway / JIRA backend 
for the community site and small number of actual JIRA users with the 
creation coming from a single user with some sort of 'community-user' data 
field patched in.  JIRA is certainly flexible and configurable this way and 
capable of interface to other enterprise apps.  We would have to find out 
how to make this work within their terms of service ...

Otherwise, its probably "BYOL" for contributors at about <$7 / month.  i.e. 
possibly "$7/month for each month active", though I think they will change 
for a constant number, which means managing floaters.  While new to this 
community, I suspect that any other arrangement than these two is 
prohibitive.  And even managing floaters for anyone not locked in by 
commitment (contract) to the group adds risk to the group from the whatever 
commitment exists with Atlassian for any fixed number.  This could 
potentially bankrupt the group if not managed correctly.

My other advice is to "KISS" when using JIRA.  All that configuration can 
lead to a tendency for organizations to attempt to solve all of their 
problems building workflows there.  This is VERY STICKY, hence the behemoth 
that Atlassian has become and will continue to be for some time in to the 
future.

Finally, any major changes such as this are like an a manufacturing 
organization changing ERP packages (been through several of those) - they 
NEVER GO WELL, and inevitably, when the smoke clears users will long for 
the old system despite its glaring deficiencies.

I therefore will hold that improvements should be made to Trac in an 
incremental Agile fashion rather than any conversion requiring a waterfall 
rollout.  This is the part where Trac should be STICKY for the group, or 
this will be disruptive.

And besides, I like Python in general and don't to fall victim to 'pay to 
play' to Atlassian / Oracle to develop open source software that, believe 
me, refers everything Python as 'a bunch of scripts'.  I get enough of that 
at work which is part of why I am here.

Regards,

Ira

On Monday, December 10, 2018 at 12:10:05 PM UTC-5, Dan Davis wrote:
>
> Tom, you are right about the UX issues, but full-text and inverted 
> indexing would help with the responsiveness as well.  Technically, I was 
> talking about djangoproject's TracSearch 
> .  That's closer to good UX as 
> well, because you can get there by progressive enhancement rather than 
> taking stuff away.
>
> You are also right that switching to another system such as github issues 
> could be a better fix than customizing Trac.   But I find it difficult to 
> believe that Github issues grows up to cover as much workflow management as 
> Trac issues or JIRA.   Maybe we need money to get JIRA.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c5b4316c-7381-46bb-aba9-535147bccc66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Dan Davis]

And there might be no need to develop code for this, only configuration:
https://github.com/dnephin/TracAdvancedSearchPlugin


On Mon, Dec 10, 2018 at 11:22 AM Dan Davis  wrote:

> I think that TracSearch could use improvement.   As an expert in
> Information Retrieval, I would be happy to help with this.   The particular
> suggestions I have:
>
>
>- Provide quick filters (e.g. facets) after a search is done based on
>ticket keywords, stage, and whether a result is a ticket, wiki, milestone,
>etc.
>- Use a Solr/Elasticsearch inverted index for better word
>segmentation, automated phrase and field boosting, etc.
>
> A search system such as TracSearch is biased towards "Recall", e.g. find
> all relevant tickets, rather than "Precision", e.g. show me only relevant
> results, and only the most relevant results.   The limits on word
> segmentation provided by RDBMS-backed full-text search often makes both
> recall and precision worse.
>
>
> On Mon, Dec 10, 2018 at 11:14 AM Dan Davis  wrote:
>
>> > I strongly dislike Trac in nearly every way. It's hard to search and
>> the filters are next to useless, and the categorisation features we use are
>> not very useful.
>> > I believe the better way to search Trac is to use google and site:
>> code.djangoproject.com which is a red flag itself.
>>
>> Is there a separate list for the infrastructure team where we could
>> continue this discussion?   I feel sure that using a better indexing plugin
>> for Trac could improve the problem.
>>
>>
>> On Sun, Oct 28, 2018 at 6:04 PM Josh Smeaton 
>> wrote:
>>
>>> I strongly dislike Trac in nearly every way. It's hard to search and the
>>> filters are next to useless, and the categorisation features we use are not
>>> very useful. I believe the better way to search Trac is to use google and
>>> site:code.djangoproject.com which is a red flag itself.
>>>
>>> On Saturday, 27 October 2018 11:09:38 UTC+11, Tom Forbes wrote:

 How much of this would you attribute to the current ticketing system
 itself, rather than tickets being tagged appropriately?

 I know when I started contributing I found trac to be pretty
 intimidating in terms of complexity, especially the search. I still prefer
 to use the 'Search Trac' field in the root code.djangoproject.com page
 than fiddle with the myriad of options and drop downs in the browse tickets
 section.

 If we think of getting new people onboard as a conversion funnel we
 need to stop dropoff as much as possible, and that extends to the UI of the
 ticket tracker as well I believe.

 Tom

 On Fri, 26 Oct 2018, 22:43 Ian Foote,  wrote:

> Hi Carlton,
>
> I've had similar thoughts sitting in the back of my mind for at least
> a couple of months, so thank you for sharing this. I agree that finding
> tickets is one of the big problems here, both for new contributors and for
> sprint leaders. At Pycon UK I took on the role of sprint leader along with
> Adam Johnson and directing people to appropriate tickets was a definite
> difficulty. I was also unaware of the django core mentorship list and will
> be joining that soon. I'm willing to spend some time mentoring a small
> number of people, life permitting.
>
> Ian
>
> On Fri, 26 Oct 2018 at 14:44, Carlton Gibson 
> wrote:
>
>> Hi All.
>>
>> OK, so last week I was at DjangoCon US in San Diego. (Thank you if
>> you organised that! Hi! if we met and chatted.)
>> I gave a talk ("Your web framework needs you!") inspired by the
>> discussion on the
>> 
>> DSF list and the proposal to dissolve Django Core
>> . (Can’t see the DSF list? Join
>> the DSF
>> 
>> .)
>> I was asking for more participation in general, and participation
>> that is more representative of the wider Django community in particular.
>>
>> There was lots of good input from many people, including (but not, at
>> all, limited to) representatives of groups such Pyladies, DjangoGirls, 
>> and
>> so on.
>>
>>
>> The recurring themes seem to me to fit into three categories:
>>
>>1. The importance of *mentoring*.
>>2. The difficulty of *finding tickets*.
>>3. The importance of *sprints*.
>>
>> The rest here is a summary of that. Hopefully it’s useful.
>>
>> Mentoring
>>
>> For whatever reasons, the exiting *Contributing How-To*
>> 
>> doesn’t lead to contributions from a demographic that matches the wider
>> Django Community.
>>
>> The point that came up again and again about this was that
>> *mentoring* is one of

Re: Widening participation (Thoughts from DjangoCon)

[Dan Davis]

I think that TracSearch could use improvement.   As an expert in
Information Retrieval, I would be happy to help with this.   The particular
suggestions I have:


   - Provide quick filters (e.g. facets) after a search is done based on
   ticket keywords, stage, and whether a result is a ticket, wiki, milestone,
   etc.
   - Use a Solr/Elasticsearch inverted index for better word segmentation,
   automated phrase and field boosting, etc.

A search system such as TracSearch is biased towards "Recall", e.g. find
all relevant tickets, rather than "Precision", e.g. show me only relevant
results, and only the most relevant results.   The limits on word
segmentation provided by RDBMS-backed full-text search often makes both
recall and precision worse.


On Mon, Dec 10, 2018 at 11:14 AM Dan Davis  wrote:

> > I strongly dislike Trac in nearly every way. It's hard to search and the
> filters are next to useless, and the categorisation features we use are not
> very useful.
> > I believe the better way to search Trac is to use google and site:
> code.djangoproject.com which is a red flag itself.
>
> Is there a separate list for the infrastructure team where we could
> continue this discussion?   I feel sure that using a better indexing plugin
> for Trac could improve the problem.
>
>
> On Sun, Oct 28, 2018 at 6:04 PM Josh Smeaton 
> wrote:
>
>> I strongly dislike Trac in nearly every way. It's hard to search and the
>> filters are next to useless, and the categorisation features we use are not
>> very useful. I believe the better way to search Trac is to use google and
>> site:code.djangoproject.com which is a red flag itself.
>>
>> On Saturday, 27 October 2018 11:09:38 UTC+11, Tom Forbes wrote:
>>>
>>> How much of this would you attribute to the current ticketing system
>>> itself, rather than tickets being tagged appropriately?
>>>
>>> I know when I started contributing I found trac to be pretty
>>> intimidating in terms of complexity, especially the search. I still prefer
>>> to use the 'Search Trac' field in the root code.djangoproject.com page
>>> than fiddle with the myriad of options and drop downs in the browse tickets
>>> section.
>>>
>>> If we think of getting new people onboard as a conversion funnel we need
>>> to stop dropoff as much as possible, and that extends to the UI of the
>>> ticket tracker as well I believe.
>>>
>>> Tom
>>>
>>> On Fri, 26 Oct 2018, 22:43 Ian Foote,  wrote:
>>>
 Hi Carlton,

 I've had similar thoughts sitting in the back of my mind for at least a
 couple of months, so thank you for sharing this. I agree that finding
 tickets is one of the big problems here, both for new contributors and for
 sprint leaders. At Pycon UK I took on the role of sprint leader along with
 Adam Johnson and directing people to appropriate tickets was a definite
 difficulty. I was also unaware of the django core mentorship list and will
 be joining that soon. I'm willing to spend some time mentoring a small
 number of people, life permitting.

 Ian

 On Fri, 26 Oct 2018 at 14:44, Carlton Gibson 
 wrote:

> Hi All.
>
> OK, so last week I was at DjangoCon US in San Diego. (Thank you if
> you organised that! Hi! if we met and chatted.)
> I gave a talk ("Your web framework needs you!") inspired by the
> discussion on the
> 
> DSF list and the proposal to dissolve Django Core
> . (Can’t see the DSF list? Join
> the DSF
> 
> .)
> I was asking for more participation in general, and participation that
> is more representative of the wider Django community in particular.
>
> There was lots of good input from many people, including (but not, at
> all, limited to) representatives of groups such Pyladies, DjangoGirls, and
> so on.
>
>
> The recurring themes seem to me to fit into three categories:
>
>1. The importance of *mentoring*.
>2. The difficulty of *finding tickets*.
>3. The importance of *sprints*.
>
> The rest here is a summary of that. Hopefully it’s useful.
>
> Mentoring
>
> For whatever reasons, the exiting *Contributing How-To*
> 
> doesn’t lead to contributions from a demographic that matches the wider
> Django Community.
>
> The point that came up again and again about this was that *mentoring*
> is one of the best (perhaps the best?) tool in helping to change this.
>
> Django Core Mentorship
>
> We don’t have an official mentoring programme but we do have the 
> django-core-mentorship
> list 
> .
>
> This must be

Re: Widening participation (Thoughts from DjangoCon)

[Dan Davis]

> I strongly dislike Trac in nearly every way. It's hard to search and the
filters are next to useless, and the categorisation features we use are not
very useful.
> I believe the better way to search Trac is to use google and site:
code.djangoproject.com which is a red flag itself.

Is there a separate list for the infrastructure team where we could
continue this discussion?   I feel sure that using a better indexing plugin
for Trac could improve the problem.


On Sun, Oct 28, 2018 at 6:04 PM Josh Smeaton  wrote:

> I strongly dislike Trac in nearly every way. It's hard to search and the
> filters are next to useless, and the categorisation features we use are not
> very useful. I believe the better way to search Trac is to use google and
> site:code.djangoproject.com which is a red flag itself.
>
> On Saturday, 27 October 2018 11:09:38 UTC+11, Tom Forbes wrote:
>>
>> How much of this would you attribute to the current ticketing system
>> itself, rather than tickets being tagged appropriately?
>>
>> I know when I started contributing I found trac to be pretty intimidating
>> in terms of complexity, especially the search. I still prefer to use the
>> 'Search Trac' field in the root code.djangoproject.com page than fiddle
>> with the myriad of options and drop downs in the browse tickets section.
>>
>> If we think of getting new people onboard as a conversion funnel we need
>> to stop dropoff as much as possible, and that extends to the UI of the
>> ticket tracker as well I believe.
>>
>> Tom
>>
>> On Fri, 26 Oct 2018, 22:43 Ian Foote,  wrote:
>>
>>> Hi Carlton,
>>>
>>> I've had similar thoughts sitting in the back of my mind for at least a
>>> couple of months, so thank you for sharing this. I agree that finding
>>> tickets is one of the big problems here, both for new contributors and for
>>> sprint leaders. At Pycon UK I took on the role of sprint leader along with
>>> Adam Johnson and directing people to appropriate tickets was a definite
>>> difficulty. I was also unaware of the django core mentorship list and will
>>> be joining that soon. I'm willing to spend some time mentoring a small
>>> number of people, life permitting.
>>>
>>> Ian
>>>
>>> On Fri, 26 Oct 2018 at 14:44, Carlton Gibson 
>>> wrote:
>>>
 Hi All.

 OK, so last week I was at DjangoCon US in San Diego. (Thank you if you
 organised that! Hi! if we met and chatted.)
 I gave a talk ("Your web framework needs you!") inspired by the
 discussion on the
 
 DSF list and the proposal to dissolve Django Core
 . (Can’t see the DSF list? Join
 the DSF
 
 .)
 I was asking for more participation in general, and participation that
 is more representative of the wider Django community in particular.

 There was lots of good input from many people, including (but not, at
 all, limited to) representatives of groups such Pyladies, DjangoGirls, and
 so on.


 The recurring themes seem to me to fit into three categories:

1. The importance of *mentoring*.
2. The difficulty of *finding tickets*.
3. The importance of *sprints*.

 The rest here is a summary of that. Hopefully it’s useful.

 Mentoring

 For whatever reasons, the exiting *Contributing How-To*
 
 doesn’t lead to contributions from a demographic that matches the wider
 Django Community.

 The point that came up again and again about this was that *mentoring*
 is one of the best (perhaps the best?) tool in helping to change this.

 Django Core Mentorship

 We don’t have an official mentoring programme but we do have the 
 django-core-mentorship
 list .

 This must be about the best-kept secret in the Django world: it’s gets
 ≈0 traffic, but I told everybody at DjangoCon about it, and that they
 should use it.

 If you are not on django-core-mentorship, and you’re willing to help
 prospective contributors, please sign-up. I’m hoping we can drive some
 traffic to it.

 Maybe there’s call for something more formal, but at least until DCM is
 actually being used, that seems (to me) like something we can postpone.

 Finding Tickets

 The next thing was that there’s not enough guidance on what to work on.

 The guidance is to look for *Easy Pickings*. There are ≈1300 accepted
 open tickets in TRAC. 13 of these are marked *Easy Pickings*.

 That’s not enough. I think we’re too tight with it (or need another
 grade).

 There are *many* tickets which aren’t super hard: I put it that, most
 of our com

Re: Widening participation (Thoughts from DjangoCon)

[Ira Abbott]

Hi,

>From the perspective of someone who just joined the group, I am glad to see 
that I was not alone not immediately finding the correct path or 
participation.  I am, however grateful that the community appears to have 
the introspection and means of moving it forward.

Being new, I am curious about "the demographic".  Could you explain?  I 
will use this as an excuse to go slightly off topic, but bring it around.

I will freely share that while I suspect I may fit some portion (male?), I 
may be skewed toward the older end (could be wrong ...)

Hint: RPG meant "Rocket Propelled Grenade" before it meant "Role Playing 
Game", and when I started playing RPGs I did so with dice and dreams of 
programming enough BASIC on my Atari cartridge computer with keyboard and 
cassette tape backup to assist in the Dice role and table lookup.  Of 
course, everyone told me that would go nowhere ...  Therefore, I obtained a 
degree in Electrical Engineering and proceeded to develop hardware and 
software in a variety of forms and using a variety of tools to this day.  I 
currently work for Imagine Communications which uses django sparsely and 
not in anything I do directly.  In fact, python itself is a rather poor 
stepchild there, but that is another story.  I love python and django - I 
feel like that kid writing BASIC again.

So my "demographic" is "newb: old fart with a bit of chip on his shoulder 
because he really does have some reasonable industry bona fides" - I have 
coworkers who have and do participate in the defined television standards 
such as HD terrestrial broadcast ("Grand Alliance") and play key roles in 
the development of a variety of SMPTE standards (of which I am a member).

Anyhow, I'm game to play to catch up and improve on my skills and maybe 
give something back if I can.

This is why I joined to share the "let's not splat because two apps use 
different SITE_ID" bit which has been causing me dig in and figure out why 
some things just don't seem to go together as an excuse to test the 
waters.  I've been going to the source rather than googling more and more.  
I don't find it all that terribly daunting and inserting a few log 
statements seems to unravel most mysteries (thanks folks that work with 
logging).  

If you find me to be a suitable test subject, I will volunteer say "Squeek" 
(i.e. consider me "available" to be a guinea pig for experimentation 
purposes).

Regardless, I am set to see how the community reacts to an minor 
improvement suggestion intended to cause no harm and possibly make a few 
lives easier with a change of a small number of lines of code.

Thanks again to everyone who past and present who has worked to make this 
framework available.  It has provided endless hours of fascination, 
excitement, and, at times , frustration. You don't develop software without 
some of the later, its the level of the former that keeps me coming back. 
Cudos.

Regards,

Ira


On Friday, October 26, 2018 at 9:44:54 AM UTC-4, Carlton Gibson wrote:
>
> Hi All. 
>
> OK, so last week I was at DjangoCon US in San Diego. (Thank you if you 
> organised that! Hi! if we met and chatted.) 
> I gave a talk ("Your web framework needs you!") inspired by the 
> discussion on the 
>  
> DSF list and the proposal to dissolve Django Core 
> . (Can’t see the DSF list? Join 
> the DSF 
> 
> .)
> I was asking for more participation in general, and participation that is 
> more representative of the wider Django community in particular.
>
> There was lots of good input from many people, including (but not, at all, 
> limited to) representatives of groups such Pyladies, DjangoGirls, and so 
> on. 
>
>
> The recurring themes seem to me to fit into three categories:
>
>1. The importance of *mentoring*. 
>2. The difficulty of *finding tickets*. 
>3. The importance of *sprints*. 
>
> The rest here is a summary of that. Hopefully it’s useful. 
>
> Mentoring
>
> For whatever reasons, the exiting *Contributing How-To* 
>  doesn’t 
> lead to contributions from a demographic that matches the wider Django 
> Community. 
>
> The point that came up again and again about this was that *mentoring* is 
> one of the best (perhaps the best?) tool in helping to change this. 
>
> Django Core Mentorship
>
> We don’t have an official mentoring programme but we do have the 
> django-core-mentorship 
> list . 
>
> This must be about the best-kept secret in the Django world: it’s gets ≈0 
> traffic, but I told everybody at DjangoCon about it, and that they should 
> use it. 
>
> If you are not on django-core-mentorship, and you’re willing to help 
> prospective contributors, please sign-up

Proposal: Allow contrib.sites to use the request host and fallback to a SITE_ID

[Ira Abbott]

We all learn very early in playing with django to set a site and a 
SITE_ID.  Once we operate as multiple sites, we either use the multiple 
processes, each configured with a separate SITE_ID or we can now pass a 
request in.  However,  I assume for backward compatibility, SITE_ID must be 
removed.  This allows all sites which specify SITE_ID to operate as if the 
addition of passing request was not added.  However, removing SITE_ID to 
allow get_site_by_request breaks all applications which do NOT pass 
request, because there is no SITE_ID.

I propose a setting, which, when set to True in addition to setting 
SITE_ID, causes request to take precedence over SITE_ID.  This will allow 
applications using both paradigms to coexist without modification - sites 
which pass request use get_site_by_request as if SITE_ID had not been 
defined and calls passing no request get SITE_ID.  When the new setting is 
not present, all behavior is backward compatible.

Essentially, I am proposing something like the 'change set' I typed in 
below - I considered that a complex and/or in the fist if could cover all 
of the conditions, but I think qualifying the first line with the new 
setting and adding the elif to cover the cleanup case of not set to True is 
easier to understand - especially in light of understanding the the 
backward compatibility aspect of the change.  The version of this change I 
am currently running simply defines a new SITE_DEFAULT_ID to catch the 
third case, but it occurred to me that some modules may expect SITE_ID 
directly for some reason, and MIXED_MODE has them covered too.  

I expect the documentation change to accompany the new setting would go 
with the Sites documentation next to SITE_ID an explanation of removing 
SITE_ID to use request.

This would be my first contribution, so I am unsure that it would welcome.  
If this ticket is accepted, I will quite gladly prepare a pull request with 
an agreed upon setting name (in case mine doesn't grab ya) or other any 
other suggested style improvements etc.

 def get_current(self, request=None):
"""
Return the current Site based on the SITE_ID in the project's settings.
If SITE_ID isn't defined, return the site with domain matching
request.get_host(). The ``Site`` object is cached the first time it's
retrieved from the database.
"""
from django.conf import settings
site_id = getattr(settings, 'SITE_ID', '')
mixed_mode = getattr(settings, 'SITE_MIXED_MODE', '')
if site_id and not mixed_mode:
return self._get_site_by_id(site_id)
elif request:
return self._get_site_by_request(request)
elif site_id and mixed_mode == True:
return self._get_site_by_id(site_id)

raise ImproperlyConfigured(
"You're using the Django \"sites framework\" without having "
"set the SITE_ID setting. Create a site in your database and "
"set the SITE_ID setting or pass a request to "
"Site.objects.get_current() to fix this error."
)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2af3d7a7-98c7-4a38-966d-b2c57da3329a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.