Re: DEP pre-proposal for a simpler URLs syntax.

[Ola Sitarska]

Hi all,

>From my personal perspective, I'd love to have that feature in Django. It'd
make a significant difference especially for beginners learning Django, as
I know that during Django Girls workshop, teaching newcomers regex is one
of the most annoying and difficult parts of learning how Django works.

If there is anything I can do to help, I'm very interested. I'll try to
find some time today to review current pull requests and see if there is a
way for me to contribute.

Thanks to everyone who has worked on this so far!

Ola

On Tue, May 2, 2017 at 11:56 AM, Sjoerd Job Postmus 
wrote:

>
>
> On Tuesday, May 2, 2017 at 7:39:06 AM UTC+2, Emil Stenström wrote:
>>
>> I talked to Sjoerd separately. He is also very busy at the moment, but
>> was working on getting merge conflicts resolved soon. He will also post a
>> list of things that are still missing, but spontaneously thought that this
>> list would be short.
>>
>
> Just a quick list of things I think/know missing:
>
>
>- There are probably some simple converter implementations missing
>(FloatConverter, IntConverter, UUIDConverter, etc), and bikeshedding might
>need to happen on the exact implementation (what regex to use). Also, these
>could be added after the main logic is already completed.
>- The more complex part is (I think) figuring out how to deal with
>cases where we have a `path('/', include(other_urls))` and
>`other_urls` also has a `path()` mentioning `something`. However this might
>just be my perfectionism and paranoia seeing edge-cases where there are
>none, or are sufficiently "edge" cases that we can suffice with a "just
>don't do it!".
>- Some positive yes/no on whether or not this is an actual desirable
>feature for Django from the core team.
>- Like I mentioned to Emil, I *think* this is "everything" that
>remains, but I might be missing a few things.
>
> Anyway, a careful review like Aymeric Augustin is suggesting might
> probably turn up a few more things that are missing.
>
> Emil: Thanks for pushing this forwards again, it got off the top of my
> mind, and it is good to have it back in focus again.
>
> --
> 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/c39a40a0-25b3-4a7b-b002-
> 767fadb38db7%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/CAFpnBuv4YFKG5qB%2BrGkZZG%2BfCcdk8zRj3XkLaDTcvkWCGLe1Qg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Ola Sitarska]

That is *awesome* :)

On Thu, Oct 6, 2016 at 9:39 AM, Tom Christie  wrote:

> > wondered if it'd be possible here to get rid of the converter in the
> syntax at all, or have a default one if none is provided.
>
> Actually yes, I'd not noted in the proposal but you can also simply use eg.
>
> path('users//')
>
> By default that'll give you the 'string' convertor. (Accepts any text
> without a slash.)
>
> I've updated the document to reflect this.
>
> --
> 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/e62c279f-4f0b-4cbc-9f98-
> 36650407835e%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/CAFpnBuuEn0QW8MovSALns4X3LU85ryPsfDUbAHs2P89e-m8FOg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Ola Sitarska]

I'm quite excited about this: it's definitely gonna solve some of the pain
points we're facing when teaching Django to Django Girls! Big +1 to include
it in core.

I recently started dabbling a bit in Rails, and wondered if it'd be
possible here to get rid of the converter in the syntax at all, or have a
default one if none is provided. For complete beginners, even figuring out
what's this `int` or `string` is again is another thing they have to think
of, and it might be beneficial to think of the really really really simple
way. Here is how Rails do it
,
and I was quite surprised how easy that is. Haven't looked into any
implementation details of current urls or new simple urls, so this idea
might be a completely wrong one, I admit :)

Good job, I'm really happy see this being worked on!

Cheers,
Ola





On Wed, Oct 5, 2016 at 9:24 PM, Robert Roskam 
wrote:

> Hey All,
>
> Sorry all. I accidentally submitted my message somehow.
>
> I wanted to say that I like the direction Django is going compared to the
> other Python frameworks for its routing. I've looked at Express.js,
> angularjs, rails, and MVC.NET as well. And Django is definitely the
> easiest to read among them.
>
> I think this syntax offers both simplicity in not missing dumb stuff like
> the leading ^ and the trailing $, but it also lets us work toward more
> expressive routing patterns in the future.
>
> Robert Roskam
>
>
> On Wednesday, October 5, 2016 at 4:08:08 PM UTC-4, Robert Roskam wrote:
>>
>> Hey Tom,
>>
>> I really like your current implementation. I think it's an elegant
>> solution to a complex problem, and I like that you looked at Flask for some
>> inspiration.
>>
>> I thought that to round out the discussion I'd do a quick comparison to
>> other frameworks. (I've added in slug examples):
>>
>> *Django*
>>
>> urlpatterns = [
>> url(r'^articles/2003/$', views.special_case_2003),
>> url(r'^articles/(?P[0-9]{4})/$', views.year_archive),
>> url(r'^articles/(?P[0-9]{4})/(?P[0-9]{2})/$', 
>> views.month_archive),
>> url(r'^articles/(?P[0-9]{4})/(?P[0-9]{2})/(?P[0-9]{2})/$', 
>> views.article_detail),url(r'^articles/(?P[\w-]+)/$', 
>> views.slug_view),
>> ]
>>
>>
>>
>> *DEP*
>>
>> urlpatterns = [
>> path('articles/2003/', views.special_case_2003),
>> path('articles//', views.year_archive),
>> path('articles///', views.month_archive),
>> path('articles', 
>> views.article_detail),path('articles//', views.slug_view),
>> ]
>>
>>
>>
>>
>>
>> *Flask*
>> Doesn't really have the idea of putting all your routes in one spot. So
>> pardon the silly example.
>>
>>
>> @app.route('articles/2003/')
>> def special_case_2003():
>>  pass
>>
>> @app.route('articles//')
>> def year_archive(year):
>>  pass
>>
>> @app.route('articles///')
>> def month_archive(year, month):
>>  pass
>>
>> @app.route('articles')
>> def article_detail(year, month, day):
>>  pass
>>
>> @app.route('articles//')
>> def slug_view(slug):
>>  pass
>>
>>
>>
>>
>> *Bottle*
>> It's basically Flask (big surprise).
>>
>> @route('articles/2003/')
>> def special_case_2003():
>> pass
>>
>> @route('articles//')
>> def year_archive(year):
>>  pass
>>
>> @route('articles///')
>> def month_archive(year, month):
>>  pass
>>
>> @route('articles')
>> def article_detail(year, month, day):
>>  pass
>>
>> @route('articles//')
>> def slug_view(slug):
>>  pass
>>
>>
>>
>>
>>
>>
>> *Pyramid*
>> This one is kind of interesting. They don't have any built in validators.
>> And they call their equivalent predicates
>> ,
>> and their usage is far more board.
>>
>> config.add_route('special_case_2003', 'articles/2003/')
>> config.add_route('year_archive', 'articles/{year}/')
>> config.add_route('month_archive', 'articles/{year}/{month}/')
>> config.add_route('article_detail', 'articles/{year}/{month}/{day}/')
>> config.add_route('slug_view', 'articles/{slug}/')
>> config.scan()
>>
>>
>>
>>
>>
>>
>> Robert Roskam
>>
>> On Monday, October 3, 2016 at 6:24:04 AM UTC-4, Tom Christie wrote:
>>>
>>> Hi folks,
>>>
>>> I wanted to push forward the consideration of introducing a simpler URLs
>>> syntax, plus support for URL parameter type conversion.
>>>
>>> A pre-proposal is available here: https://gist.github.com/tomchr
>>> istie/cb388f0f6a0dec931c611775f32c5f98
>>>
>>> At this point I'm seeking feedback, before hopefully iterating on the
>>> proposal, and making a formal submission.
>>>
>>> I'm not making any assumptions right now about where this might get too,
>>> or who'd be involved if it does make it to the DEP stage, and would very
>>> much welcome outside involvement. I'm also aware that while there's been
>>> some positive reception, it's not yet clear if we'll reach a consensus on
>>> inclusion in core.
>>>
>>> 

Re: Testing pre-release Django

[Ola Sitarska]

The way we do it for Djangae  right
now is creating a `support-110` branch whenever we've got some capacity to
start working on it, or we wanna assess the amount of work required. Here
is a current status for our Django 1.10 support
.

However, we're aiming to move into making nightly builds on Travis that
would include running tests on all supported Django versions + django
master, once a day. It doesn't seem trivial though (seems like we will need
to run our own version of https://nightli.es/ to run this build on
different branch than master). Hopefully this will allow us to catch big
breaking changes earlier, even before alpha is out.

On Wed, May 25, 2016 at 11:57 AM, James Pic  wrote:

> I've found testing your own projects on django master to be
> tremendously useful. Then, I don't have any surprise when I test on
> django alpha, everything passes and I have nothing to do. Not to
> mention the tremendous amount of things I learn on the way, at a
> slower, more regular pace. Compare this to before, when I was waiting
> too long to test against the new/next version of django, had to face a
> ton of different failures at the last minute, had to go and couchsurf
> at another contributor's house to peer-hack at night after our
> dayjobs. BUT that's how I made a best friend for life and that's
> priceless hehe even though I wouldn't hold this as a technical
> argument for not testing against master !
>
> I guess each person will have a different opinion. Nowadays, I add
> djangomaster to my test matrix on all projects, in "allowed failures",
> and find out it's broken every once in a while, and just have 1
> problem to fix at the time. It works very well for our community, so,
> definitely worth trying and then deciding if that's how you want to
> work or not.
>
> --
> 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/CALC3KafR7NLJryntqAo7LkiBL3YMfk_yjLgs%3D2%3D_%2BJsnSTd_QQ%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/CAFpnBuuq%2BeTCXV9bXW81%3Dv6ckOHEmsUKspx%2B9cbQEf_FE7uShw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Decoupling the ORM

[Ola Sitarska]

I'm definitely not going to be more helpful than Anssi, but feel free to
take a look on Djangae , a Django
database backend for non-relational datastore on Google App Engine. We've
also got a chat and a mailing list if you wanna have a chat with us.

Here are also some implementation details
.

On Wed, Dec 16, 2015 at 7:33 AM, Anssi Kääriäinen 
wrote:

> On Tuesday, December 15, 2015 at 5:43:55 PM UTC+2, Samuel Bishop wrote:
>>
>> Having worked through the code of several Django nosql/alternative
>> database backend libraries, forks, etc...
>>
>> I've noticed that that one of the biggest challenges they run into, is
>> 'conforming' to many of the things Django expects these lowest layers to do.
>>
>> I opened this ticket https://code.djangoproject.com/ticket/25265 to
>> begin getting feedback on an initial idea for how to 'fix' the problem.
>> Since then I've had further time to ponder the problem and while it still
>> seems to me that the best mechanism is to draw a line between the 'upper'
>> and 'lower' layers of Django,
>> I'm no longer 100% sure the correct place to enable this is the queryset
>> via an additional method, because I've realized that this is not just an
>> opportunity to get NoSQL databases into Django, but also an opportunity to
>> finally provide support for alternative Python ORMs, such as SQLAlchemy.
>>
>> I've been digging around the code for this so I dont mind writing up the
>> code for this, but there is the big question of 'where to decouple' things.
>> Initial feedback in the thread
>> https://code.djangoproject.com/ticket/25265#comment:4
>> 
>> has raised the suggestion that moving one layer further up may be the right
>> place to go. It would be very helpful for me to get extra input from Django
>> developers familiar with the QuerySet and Query, before I start writing, so
>> I would love to hear feedback on the idea.
>>
>
> Assume the goal is perfect admin integration with a MongoDB backend. The
> approach can be either:
> 1) Use Django's standard models, create a QuerySet compatible
> MongoDBQuerySet.
> 2) Use completely different models, which respond to the APIs needed by
> Admin. This includes implementing a QuerySet compatible MongoDBQuerySet.
>
> There is a lot more work to 2), but the benefit is that you get to use
> models actually meant to be used with a non-relational backend. For
> example, Django's User, Permission and Group models are implemented in a
> way that makes sense for a relational backend. If you use relational schema
> on non-relational database you are going to face big problems if you try to
> run the site with any non-trivial amount of data. For this reason I believe
> 2) to be the right approach.
>
> But, to get there, a QuerySet compatible MongoDBQuerySet is needed
> anyways. Here the choices are those mentioned in
> https://code.djangoproject.com/ticket/25265#comment:4
> .
> That is, you can go with Django's QuerySet and Query, and just implement a
> MongoDBCompiler. Or, you can use QuerySet with MongoDBQuery class. Or,
> finally, you can implement MongoDBQuerySet directly from scratch.
>
> If you implement Compiler or Query, you are targeting internal APIs which
> we *will* change in the future, maybe even in dramatic ways. If you target
> QuerySet, you are targeting a public API that doesn't change often. And,
> even if it changes, you will get a nice deprecation period for the changes.
>
> It might seem a lot of work to start from QuerySet, but for a
> non-relational backend there isn't actually *that* much work involved. Most
> of Django's Query and Compiler classes deal with joins, SQL's NULL
> peculiarities or SQL's way of doing aggregations. All of these are
> non-issues for non-relational backends.
>
> So, I think you should start with implementing a custom QuerySet for your
> wanted backend. You can also try to make it work with all Django models,
> but that approach is very likely to fail. For starters, Django's models use
> an autoincrementing integer field for primary key, whereas most (if not
> all) nonrelational databases use something different. Another interesting
> case is ManyToManyFields, which assumes a relational data model.
>
> It is very tempting to go with an approach where you just implement a
> custom Compiler class for your nonrelational backend. This would, in
> theory, allow users to run any existing Django application on
> non-relational database by just using a non-relational backend. The problem
> with this approach is that it doesn't work well enough in practice, and the
> maintenance overhead in the long run 

Re: Fellow Report - October 17, 2015

[Ola Sitarska]

Thanks Tim, great job.

If anyone is interested in installation of Python & Django on Windows,
beginner friendly instructions are here
. I heard from
RailsGirls friends that Ruby/Rails situation on Windows is indeed a lot
harder than ours.

On Sun, Oct 18, 2015 at 9:49 AM, Aymeric Augustin <
aymeric.augustin.2...@polytechnique.org> wrote:

> Thanks Tim!
>
> Having CI on Windows is great, all the more considering your reminder that
> new programmers often use Windows.
>
> I'm looking forward to Michael's proposal for the MSSQL roadmap.
>
> --
> Aymeric.
>
> Le 18 oct. 2015 à 02:36, Tim Graham  a écrit :
>
> Report for week ending October 17, 2015:
>
> This week I spent three days at Microsoft HQ in Seattle at the first "open
> source data camp". As I understand it, the "data camps" are normally held
> to inform Microsoft partners about current and upcoming offerings in
> Microsoft cloud services and to get feedback about them. This session was
> the first time that they invited members of the open source community (3
> for Django and 2 for Rails) as well as some startup/small business people
> who use open-source software (5 others).
>
> Both groups were together on day one: an overview of Microsoft's cloud
> offerings and some technical discussion with Microsoft engineers about
> those products. This wasn't of much interest to me, but the idea seemed to
> be that we had to sit through this because the "data camp" budget was used
> to allow us to attend. On days two and three, the "users group"
> participated in more talks while the Django & Rails attendees worked with
> Microsoft engineers to give them some insight on what's needed to improve
> MSSQL/Azure database support as well as to actually write some some code.
>
> Some of the things we accomplished:
>
> * Completed an initial Jenkins integration on Windows: Microsoft engineers
> helped fill the gaps in my knowledge so that we could get our Jenkins CI
> infrastructure running the tests on Windows (SQLite, Python 2.7 + Python
> 3.5 only; however, I think this should be sufficient for now as I can’t
> remember a time when we received a bug report for a database-specific
> Windows issue). I’ll probably add pull request integration once things are
> running smoothly. We still have at least one time-dependent test failure on
> Windows (ticket #25562). Unfortunately, the setup process on the Windows
> slave is entirely manual (unlike the setup of the Linux machines which is
> automated with Ansible playbooks), however, it's not very difficult once
> you know the steps which I'll document when I get a chance. An idea from
> one of their engineers was to try Appveyor (think Travis CI for Windows)
> and got a test integration working there as well. It's an option if the
> Jenkins solution proves difficult to maintain, but I think there's no need
> to add a new service to our workflow for now.
> http://djangoci.com/job/django-windows/
>
> * Improved teardown strategy in schema tests to fix MSSQL support: Michael
> had some work on the 1.7-era on this, but the patch was never committed and
> didn't entirely work, so I updated it and merged it to master, 1.9, and
> 1.8: https://github.com/django/django/pull/5433
>
> * Investigated speeding up the django-mssql test suite: It takes something
> like 8 hours due to excessive constraint checking enabling/disabling which
> is very slow on MSSQL. This is no longer an issue on Django 1.9+ due the
> removal of deprecated initial data fixture loading, however, some solution
> for 1.8 seems important. I've proposed a pull request and am awaiting
> Michael's testing of it: https://github.com/django/django/pull/5438
>
> * Discussed the long-term roadmap for MSSQL support in Django. I'll let
> Michael speak to the details of this.
>
> On the last day, I wondered "what's next?" and voiced my skepticism about
> Microsoft following through with the resources to get support for Microsoft
> databases on par with our built-in database backends. During a conversation
> with Meet Bhagdev, the Microsoft program manager who invited us, I shared
> my idea of Microsoft hiring someone full-time to not only maintain the
> Microsoft database backends, but to participate in the Django community at
> large, a sort of "Microsoft Django fellow". Meet thought this wasn't out of
> the realm of possibility and encouraged me to bring it up at the executive
> Q that day with two of the SVPs. The execs seemed open to the idea and
> suggested it's mostly dependent on finding the right person. If you or
> someone you know is interested in this, let me know and I'll pass your name
> along.
>
> There were also two Ruby on Rails community members in attendance. They
> learned about some difficulties of installing Rails on Windows and how
> that's really a diversity issues since most new programmers will be on
> Windows. That's something for the Django community to keep in 

Re: documenting changes to the database backend API

[Ola Sitarska]

Hi Tim!

At Potato we're developing Djangae: https://github.com/potatolondon/djangae,
which is a database backend for supporting Google App Engine datastore.
We're currently only supporting 1.6, but we're about to start development
of 1.7 support.

Thanks!
Ola

On Fri, Jan 9, 2015 at 5:00 PM, Tim Graham  wrote:

> To authors of third-party database backends,
>
> We'd like to start documenting changes to the database backend API [1],
> but we need some help with this.
>
> First, please introduce yourself and which backend you maintain so we know
> of your existence.
>
> Second, we'd like to know if you attempt to support multiple versions of
> Django in a particular release of your backend? This will help us to decide
> whether or not try to document the changes in a backwards and forwards
> compatible way.
>
> Third, could you try updating your backend to 1.8 and let us know what
> problems you run into so we know what documentation to add?
>
> The section of the release notes that will be expanded with details is:
> https://docs.djangoproject.com/en/dev/releases/1.8/#database-backend-api
>
> Thank-you!
>
> [1] https://code.djangoproject.com/ticket/24106
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/a9c2aefc-f6f0-46db-804a-3608d033017c%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFpnBuuVQ8LyX51QA-nUbbUmK6yxMfkjieoTXZNDep6qtR%2Buww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Requiring GitHub login for actions on Trac

[Ola Sitarska]

I think that much better option would be to link "Code" in header of 
djangoproject.com to 
this: https://docs.djangoproject.com/en/1.6/internals/contributing/ and 
make this a landing page for people who want to contribute. 

As a newbie contributor I found it super helpful :)

On Friday, August 15, 2014 2:29:02 AM UTC+2, Russell Keith-Magee wrote:
>
>
> On Thu, Aug 14, 2014 at 7:20 PM, Aymeric Augustin <
> aymeric.au...@polytechnique.org > wrote:
>
>> Hi Russell,
>>
>> It seemed to me that this page wasn't nearly as good an introduction to 
>> contributing to Django as the contributing guide from the official docs, so 
>> I trimmed it and pointed to the docs instead.
>>
>> In fact, I started by removing incorrect or outdated information — for 
>> instance, the workflow described in the page dated back to the pre-git era, 
>> replacing get_absolute_url appeared to be the main current project while no 
>> one has worked on it for years, etc. A few minutes later there was so 
>> little left that I simply rewrote the page.
>>
>> Generally speaking, I don't believe we'll ever manage to keep the wiki 
>> sufficiently accurate and up to date to make it useful. Last year I tried 
>> to look for spam links (with a script) and scrub them, but there were so 
>> many that I gave up. In my opinion, the viable alternative to our 
>> self-hosted wiki is called the World Wide Web :-)
>>
>> Feel free to restore and perhaps update the previous content. I believe 
>> it did more harm than good, but as long as it remains clear that you need 
>> to authenticate before you can file a ticket, we'll be all right!
>>
>> Hi Aymeric,
>
> Your reasoning makes sense - I can't argue that some of the content there 
> was a bit stale. However I think there's a middle ground - that particular 
> page is the landing page for people who want to contribute, so it needs a 
> bit more than a curt "get thyself a github account". 
>
> I'll work on improving what's there.
>
> Russ %-)
>

-- 
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/7ee2ad46-f0db-4d5f-be70-83d2f1dabf80%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

DjangoCon Europe tickets on sale today!

[Ola Sitarska]

Hi everyone! 

I'm Ola, one of the main organizers of upcoming DjangoCon Europe 
conference. I just wanted to let you know that we're starting to sell 
regular tickets to the conference today at 4pm CET prompt! Tickets are 
available here: http://tickets.djangocon.eu/

We have also recently announced venue <http://2013.djangocon.eu/venue/>, 
schedule <http://2013.djangocon.eu/schedule>, 
talks<http://2013.djangocon.eu/talks/>
 and speakers <http://2013.djangocon.eu/speakers/>. We would love to hear 
you thoughts and ideas for DjangoCon -- please, let us know what we can 
improve to make this event ever more awesome :) 

Really looking forward to meet you in Warsaw!

--
Ola Sitarska
http://2013.djangocon.eu/

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.