Re: Official Projects DEP

2016-07-19 Thread Chris Foresman
Nice work!

On Thursday, July 14, 2016 at 10:36:19 PM UTC-5, Andrew Godwin wrote:
>
> I am happy to report that the Official Projects DEP, number 0007, was 
> approved by the Technical Board and is now adopted as final!
>
> Andrwe
> On 4 Jul 2016 11:39 am, "Andrew Godwin" > 
> wrote:
>
>> I've revised the documentation section for clarity about external 
>> hosting, and given the lack of further discussion or dissention, I'm now 
>> taking the DEP to the technical board for a decision.
>>
>> Andrew
>>
>> On Sun, Jun 12, 2016 at 4:35 AM, Andrew Godwin > > wrote:
>>
>>>
>>> On 12 Jun 2016 2:00 a.m., "Tim Graham" > 
>>> wrote:
>>>
>>> >
>>> > 1. It might be nice if projects had more than one shepherd so there's 
>>> not a single point of failure. Of course, if all members of the maintenance 
>>> team end up joining the team, then there's no issue.
>>>
>>> It depends how the role of work is split between them; I think it 
>>> depends on the project too. I'd rather not over legislate here and let us 
>>> have some leeway based on context. I agree we should aim for this if the 
>>> shepherd role is very busy for that project, but with a maintenance team we 
>>> hopefully have a ready source of knowledgeable potential new core team 
>>> members.
>>>
>>> >
>>> >
>>> > 2. Re: "The main project documentation does not have to be hosted 
>>> inside the main Django documentation, but should be under an official 
>>> Django domain if possible, and link back to with the main Django 
>>> documentation where it makes sense."
>>> >
>>> >
>>> > I'd rather not get into hosting more documentation on 
>>> djangoproject.org if possible, as there's a non-trivial maintenance 
>>> burden there. I imagine it would be easier for the project's maintenance 
>>> team to make adjustments in the readthedocs UI instead of bothering the 
>>> Django ops team in the event of any problems.
>>>
>>> This is why I said domain, not infrastructure; I'd like us to host on 
>>> RTD with a custom django project subdomain so we retain control of the URLs 
>>> in the long term but we can pay them to host and deal with it all in the 
>>> short term.
>>>
>>> >
>>> >
>>> > 3. Did you envision any involvement from the Django Fellow in these 
>>> projects? To date, I haven't really had much involvement with any of the 
>>> ancillary projects like localflavor and formtools.
>>>
>>> I didn't, mostly as I didn't want to add more responsibilities to the 
>>> existing set; do you think we should? I think asking the project to come 
>>> with a plan for that stuff is helpful, and if it would need Fellow 
>>> involvement, the proposal should include them as part of the maintenance 
>>> team maybe?
>>>
>>> Andrew
>>>
>>> >
>>> >
>>> > On Friday, June 10, 2016 at 3:01:23 AM UTC-4, Andrew Godwin wrote:
>>> >>
>>> >> Just to update on this, there was some good feedback on the draft for 
>>> writing and clarity, and it's now made it into an official draft, located 
>>> here: 
>>> https://github.com/django/deps/blob/master/draft/0007-official-projects.rst
>>> >>
>>> >> If you'd like to read through the draft and raise discussion points 
>>> or opinions on the plan, now is the time!
>>> >>
>>> >> Andrew
>>> >>
>>> >> On Wed, Jun 8, 2016 at 1:34 PM, Andrew Godwin  
>>> wrote:
>>> >>>
>>> >>> Hi everyone,
>>> >>>
>>> >>> I've started on an "official projects" process DEP as I discussed 
>>> here a while back, to formalise the process of adopting non-core packages 
>>> as repositories under the official Django organisation, with a view to 
>>> taking Channels on this route (and hopefully including the existing 
>>> localflavor under this too).
>>> >>>
>>> >>> Pull request is up here: https://github.com/django/deps/pull/23 - 
>>> comments welcome.
>>> >>>
>>> >>> Andrew
>>> >>
>>> >>
>>> > -- 
>>> > 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/2d85ebf4-2699-4faf-bb3a-d9c213b76fe2%40googlegroups.com
>>> .
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/06a46b6c-7690-4804-a0

DjangoCon US sprints communication (IRC is blocked)

2016-07-19 Thread Tim Graham
Many ports are blocked on the conference network, including 6667 for IRC. 
Does anyone have a preference about whether to use a slack channel or to 
stick with #django-sprint on IRC and recommend something like IRCCloud to 
bypass the firewall? Or do you have any other ideas?

The sprints are on Thursday and Friday for anyone interested in 
participating remotely.

-- 
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/4116a1cf-75b6-4bd4-90a4-fe41334beec2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: DjangoCon US sprints communication (IRC is blocked)

2016-07-19 Thread Shai Berger
On Tuesday 19 July 2016 21:50:16 Tim Graham wrote:
> Many ports are blocked on the conference network, including 6667 for IRC.
> Does anyone have a preference about whether to use a slack channel or to
> stick with #django-sprint on IRC and recommend something like IRCCloud to
> bypass the firewall? Or do you have any other ideas?
> 

There is http://webchat.freenode.net/ -- to log in, 

/msg nickserv IDENTIFY username password

Then you can /join any channel.


Translatable Site.name

2016-07-19 Thread James Pic
Hi all,

Are there any plans to make Site.name translatable ?

Would that be something we want to offer as a feature ?

Thanks

-- 
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/CALC3Kad1CEEpvz%2B4e6_qFO9x6Ya%2BjrFUsFN0TjA8KrVJACGQ2A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Translatable Site.name

2016-07-19 Thread Shai Berger
On Wednesday 20 July 2016 01:43:05 James Pic wrote:
> Hi all,
> 
> Are there any plans to make Site.name translatable ?
> 

Site.name is a model field.

Translatable models are a big hairy issue. Several solutions have been 
suggested, each with its own pros and cons. Last time I looked (several years 
ago), we were not at the stage where we could bless one of them.

> Would that be something we want to offer as a feature ?
> 

Site.name as a single, special-cased translatable field? I don't believe so.

Shai.




Re: Translatable Site.name

2016-07-19 Thread Tim Graham
If we were able to switch to declaring sites as settings rather than as 
models as described in 
https://groups.google.com/d/topic/django-developers/OGOf1TfSBBs/discussion, 
I believe it would be more feasible.

On Tuesday, July 19, 2016 at 7:11:03 PM UTC-4, Shai Berger wrote:
>
> On Wednesday 20 July 2016 01:43:05 James Pic wrote: 
> > Hi all, 
> > 
> > Are there any plans to make Site.name translatable ? 
> > 
>
> Site.name is a model field. 
>
> Translatable models are a big hairy issue. Several solutions have been 
> suggested, each with its own pros and cons. Last time I looked (several 
> years 
> ago), we were not at the stage where we could bless one of them. 
>
> > Would that be something we want to offer as a feature ? 
> > 
>
> Site.name as a single, special-cased translatable field? I don't believe 
> so. 
>
> Shai. 
>
>
>

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