Re: Default upload permissions

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 proj

Re: Widening participation (Thoughts from DjangoCon)

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 ultimat

Re: Widening participation (Thoughts from DjangoCon)

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

Re: Widening participation (Thoughts from DjangoCon)

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 man

Re: Widening participation (Thoughts from DjangoCon)

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 >

Re: Widening participation (Thoughts from DjangoCon)

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 s

Re: Widening participation (Thoughts from DjangoCon)

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 wit

Re: Widening participation (Thoughts from DjangoCon)

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, wi

Re: Widening participation (Thoughts from DjangoCon)

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

Re: Widening participation (Thoughts from DjangoCon)

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

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

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.