Reworking the order and pace of the tutorial

[zanderle]

I'm working on a more significant rework of the tutorial and wanted to hear your thoughts on the matter.

I've been working with a professor at my uni, who is dealing a lot with the teaching/learning of algorithmic thinking. He teaches Programming to the first year students, who have varying (usually little to none) experience with it. He also teaches a course called Teaching of algorithmic thinking. Based on his extensive experience with teaching programming/algorithmic thinking for people with little to no experience with it, based on the latter course, and based on our own experience mentoring DjangoGirls Ljubljana last year, we observed ways in which this tutorial might be improved.

Given its target group (newcomers), we observed this tutorial might be a bit overwhelming for a one day workshop. I am thrilled that it is successful at getting these newcomers excited about coding and that it presents the material in an approachable way. I also believe it could be greatly improved at introducing these important (and some fundamental) subjects to newcomers and make the whole tutorial easier to grasp for someone who has never seen a command-line.

The changes would mostly include different order of the tutorial and the scope size at specific stages. For example, from an educational and motivational standpoint it makes much more sense to start with HTML before anything else.

I have to push the initial changes and will then link to my fork so we can discuss this further. I can also explain the proposed changes, if required. Firstly, I just wanted to make a short introduction first :)

[aniav]

Hello @zanderle, there were a few ideas for such rewriting before so it's good you have started this topic as more people may give their voice on that. I remember there were a few constraints and concerns on this. As the beginning you might look at #208. Thanks! :)

[zanderle]

@aniav cool, that's great to hear :) ! I'd love to hear those constraints/concerns, so we'll be able to address them. But I guess they'll come up after I present the proposed changes :)

[olasitarska]

Hi @zanderle! Thanks for getting involved, and willingness to put so much work into making this tutorial even better! :)

To give you our opinion if we agree with changes you're proposing, we need to know what changes you would actually like to implement. Different order and scope is simply not enough detail to judge it.

One problem I am seeing already, is the fact that we currently have 7 translations, with 8th being published right now. Any significant changes will have to be really well argumented, as it involves not only changing the English version, but huge amount of work for all translators. It doesn't mean that we want translations to stop development of English version, but we are super extra careful when making big changes like that, if they may or may not work.

You also mentioned moving HTML chapter earlier -- I believe this topic has been discussed many times already, and general conclusion is that moving it earlier may discourage attendees with going any further, because they will like HTML enough already, and would like to purse programming in this direction. That's why we haven't moved it yet.

[zanderle]

@olasitarska thanks for the feedback! Yes, it makes sense you can't comment on it, since I haven't provided anything concrete yet. Working on it :)

I am meeting with the professor a bit later, and I will make sure I bring up your points. Thanks!

[olasitarska]

Sure! I'm looking forward to see and discuss your ideas :)

[zanderle]

Proposed changes to the tutorial

As I've mentioned in the earlier post, this proposal is based on my professor's and my own experience mentoring DjangoGirls Slovenia last year and based on his experience teaching programming to various age groups as well as his class Teaching algormithmic thinking. Given that this tutorial is already translated into 7 languages, we tried to keep as much of the tutorial intact, which would allow for an easier transition, if the changes would take place.

When considering what we think would need to be changed, we followed three basic guidelines, that are fundamental to effective teaching of programming/algorithmic thinking (or any subject for that matter). These are:
1. Motivation. Whenever teaching a new concept, it should be taught as a resource to something greater (to solve a bigger problem for example). The goal/motivation should be something that is relevant to the person that is being taught. It will give the student a context and an understanding of why this new concept is important (versus "trust me, you'll need this").
2. Teach one concept at a time. It is important to teach one concept at a time, otherwise it quickly becomes overwhelming for the student and it makes it much more difficult to understand what is going on. It is also important to teach only the things that are needed to solve the task at hand (this relates to the first point) - otherwise, things lose context and can get out of hands.
3. The student should feel confident about the task at hand. When teaching new concepts, it is important to have the tasks at the student's level. It means it should contain little to no "magic". Student should understand the whole (or at least most of it) task at hand, ie there should be no concepts involved, that they don't understand yet. For example "you won't understand this yet, but do it in such a way, and it will work".

Note: I will be referring to these 3 guidelines as (1), (2) and (3) throughout this proposal.

Before I list the proposed changes, please know that this is all coming from wanting to make this an even better tutorial and have all the DjangoGirls attendees take the most out of the workshop. If you find a change that doesn't make sense, or feel that it shouldn't be in the tutorial, please let me know so that I can explain my reasoning behind it and so that we can find some common ground.

Here we go.

I put the proposed changes in three parts. The proposed order, changes to the specific chapters, and the reasoning behind it.

The proposed order

• Introduction
• Code editor
• Introduction to HTML
• CSS - make it pretty
• How the Internet works?
• Introduction to command line
• Python installation
• Django installation
• What is Django?
• Deploy!
• Introduction to Python
• Django urls
• Django templates
• Template extending
• Django models
• Django admin
• Django views - time to create!
• Django ORM (Querysets)
• Dynamic data in templates
• Extend your application
• What's next?
• Django Forms
• Starting Django project

Specific chapters

Note: I omitted the chapters that require practically no changes.

Introduction to HTML

I think HTML is a great starting point, since it's quite easy to understand and the results are visible right away. Now isn't that a great way to start the tutorial :)
This is great because of (3). However, it's also important to have some motivation behind it (1). For this, I thought it would be a cool idea for the attendees to create a CV. I was trying to think of something that would make sense creating in HTML, while at the same time being relevant to the target group.

So I would leave this chapter mostly as it is, except add a task - build your own CV (or for an imaginary person, if someone didn't feel comfortable doing their own) - and an example of it. This would provide great context and understanding of what HTML is for.

EDIT : The CV idea is only for the first few chapters. The main goal of the tutorial is still a blog. Not sure if that was clear or not.

CSS - make it pretty

This would stay the same, except relate to the task at hand - creating a CV.

How the Internet works?

Up until this point, the students would create a cv.html and open it with browser directly (without serving it a web server). The tutorial would explain that this is basically what the internet is - showing some files. It would then go on and explain that if you want to do, what we just did locally, on the internet, you would need a web server. This would transition really well into why we need Django (this satisfies (2)).

So basically the chapter would mostly stay the same, except add some context, with the help of referring to the task we added.

What is Django

This chapter would stay the same as far as the Django explaination goes, but I would add more content.

I propose that the tutorial would work better with a project that was prepared in advance. This would help with (2) and (3). Just a simple Django project that the students can download and not worry about various configuration. This would be added to this chapter.

Here is an example of such project. Keep in mind it's a work in progress and I'm only linking it to make it a bit clearer - it's not at all finished. Just as an example of scope of such project.

So then, continuing from the previous chapter 'How the Internet works?', we could explain why we need Django at have it serve our cv.html. Instead of them having to create a project and set everything up, they could simply use the existing project, and just copy-paste their cv.html into index.html. And when they ./manage.py runserver they would see the results right away. This works heaps towards (1), (2) and (3)!

Deploy!

To keep on with the great results they've been getting, it would be awesome if they deployed their project right away and be able to see their website online. I would keep the chapter the same, except simplify it where possible, with the help of a pre-made project.

Introduction to Python

Simplify this chapter a bunch - we only want to teach as much Python as will be needed in the following chapters (relates to (1) and (2)). Defining new functions and if...else could be dropped [1] entirely.

One could argue, that we need to explain function definition, since we'll be creating view functions later on. I think this can be omitted, and the view definitions be presented as 'here we will define a view' without explaining that it is actually a function.

[1] See a note at the end of the proposal, relating to what I mean, when I say 'drop' this part.

Django urls

Following the (1), we can say something like "Ok, we have a website, and it is showing our resumé. What we really want, is have the website show our blog first and then at /about/ url, show our CV."

So the chapter could stay mostly the same, only the context and a task would be added.

Template extending

Again, this would mostly stay the same, except add some context. Since we already have cv.html and want to create a blog now, we want some layout that we don't want repeating...

Django ORM (Querysets)

Drop the explaination about creating new instances, as we don't need that yet, nor do we need it in the following chapters (relates to (2) and (3)).

Django Forms

I moved this and 'Starting Django project' to the end, since I think they should be regarded as 'optional'. Not sure if this means just moving them to the end of the tutorial, or moving them out completely to Django Girls: Extensions.

The reasoning

Like mentioned at the beginning, the reasoning behind every single change is to follow the fundamental rules to effective teaching. I believe the tutorial should be understood as easy as possible by someone with no prior experience. Since the tutorial is already great, and really good at explaining specific concepts, I focused mostly on adding context (1), separating new concepts (2) and reordering, so that the results are visible as soon as possible (3). I believe all this would increase the effectiveness of the tutorial by great amount.

Regarding the parts of the tutorial, I said I would drop or simplify. This was proposed with the people with no experience in mind. However, since the tutorial is online and available for referrence even after the workshop and since people will have varying knowledge of specific concepts, I understand the importance of also including these subjects. So I am not sure what the best solution would be. I see two options. First one is that these concepts would be moved out of this tutorial and into 'Extensions'. Second one would be to leave them in the tutorial, but 'remove' them from the main flow, by marking them as 'optional' or 'advanced'.

Please let me know what you think. If needed, I would be happy to discuss this over Skype/Hangouts as well.

Best,
Žan

[zanderle]

I'm also cc-ing my professor, in case he wanted to add something. @janezd

[olasitarska]

I feel it'd be easier to comment on, if we have it on Google Docs, to allow commenting on small parts without going crazy. Does this approach to talk about this make sense? If you agree, could you create a doc and link it here? :)

[zanderle]

@olasitarska yup, makes sense :) Link to Google Docs

[olasitarska]

Ok, I spammed you with some comments there. In general, I'm impressed, and I really like it. I see two problems at the moment, all summed up at the last comment of that doc. It's pretty late here already, so if I missed something, let me know!

[olasitarska]

Also, THANK YOU for this amazing effort, you're a true legend :) Good night!

[zanderle]

Thank you so much for being really fast with your feedback. I really appreciate that!

I'm copying your general comments here for clarity.

Ok, so overall I think I really really like it, and I think all of that would be a significant improvement, so thank you so much for taking the time to do this!

Thank you, I'm really happy to hear that! :)

However, I'm not a fan of two things:

• adding additional CV task. seems a bit pointless, and I don't see what we're achieving through that, other than risk of increasing the time of accomplishing the tutorial, and complicating it more.

Yeah, I agree. The CV task was only meant as something that would allow for tinkering with HTML right away. Something that is easy enough but also has some sort of structure to it. I agree that CV is probably not the best idea. Maybe a static blog is better. Or a homepage to a blog, or something like that. Like I said, I'd love to have something that is easy and has some structure to it and allows tinkering with it right away.

• giving people pre made Django project -- this definitely goes against our approach of not taking shortcuts, even if we're doing annoying or difficult concepts; it introduces magic, and a lot of unknown.

I think there is a fine line between introducing too much at once and hiding too much. We definitely need to find a balance here. So my reasoning for pre-made Django project is mainly that without it, they have to do a lot of hard work before getting anywhere. Hard work full of new concepts, that they probably won't understand at first. It also makes deploying a lot harder than it needs to be.
On the other hand, a pre-made Django project allows us to explain one concept at a time. Which I think is crucial. Otherwise, things get overwhelming.
You say it introduces magic and a lot of unknown. I would argue that by forcing them to create a Django project on their own, things get a bit out of hands - before seeing their page (which is all we want at this point), they have to create a new project, add a new app, tinker with settings.py, edit urls.py, create a view. All of this requires explanations. While it does make everything transparent, I believe it's too much to do all at once.

Having said that, I do think we need to find a common ground for this. For this, I think it's important that the pre-made project is as basic as it gets. And in the tutorial, we would have both options available. So a pre-made project route, which allows for easier explanation and a way to have a better flow throughout the tutorial. And instructions on what steps to take to get to that pre-made project on your own (basically the existing instructions).

I was talking to a friend earlier, who was also mentoring Django Girls last year. He made a really good point about why it's important to not make things overwhelming (basically why it's important to follow (3)). He said that introducing many difficult concepts, without having the time to properly explain them, can have detrimental effect. It can leave attendees feeling that this is too difficult and that they are not getting it. For some people, it can easily be a sign that "this just isn't for them". That is why I think it's so important that we don't make the tutorial overwhelming and that it doesn't become information overload.

PS I will reply to the google docs comments later or tomorrow. It's pretty late here as well :)

[keikoro]

I'm not sure if it's okay to butt in here, but I feel the proposed change re: a ready-made Django project would make the Django Girls tutorial a lot more similar to the Rails Girls guides (just based on a different programming language).

The Rails Girls guides are much more about "magic" and don't dig too deep into actual programming, and from my experience (as organiser of/coach at several RG events), the workshops seem to attract more people who only want to take a superficial look at programming and don't leave as many participants wanting to continue learning to program after the event.

Which is fine, of course, but as someone with an actual interest in programming, I've always liked that Django Girls seem to take the programming part as well as getting more people truly interested in learning to code more "seriously".

[janezd]

Here's an opinion about magic from an outsider - I've never mentored at Rails and only once at Django. Besides, I've been teaching Python for 7 years (as Programming 101 for CS majors), but my experience in Django is limited to adding some views and even admin scripts to a project that is otherwise maintained by others. So for me things like python manage.py makemigrations blog or python manage.py migrate blog are basically magic. Well, not really, I understand migrations, but whenever I need to do something like this, I just blindly follow the recipe. (Like when you do something bad with your git repo and then invoke the incantation you find on StackOverflow.)

As a teacher, I hate magic; I like Python precisely because I can get through entire course without any I'll-explain-this-laters, except for a few from XXX import * in the first lectures. But in a single-day Django Girls event, there will inevitably be some magic. If we can explain it, that's fine. But "The last step here is to add our new model to our database. First we have to make Django know that we have some changes in our model (we have just created it!)." is not really an explanation - I doubt that girls understand it, although we pretend to have taught them what's a database and a model. When we have a choice between "copy this line to the terminal and press Enter" or "download this from github", I don't see much difference. And I would generally prefer using predefined projects than losing time by copy/pasting from instructions, when this can be avoided. (I know my examples here are bad, database has to be configured locally.)

Once again, I don't know Django well and while I do have a lot of experience teaching Python, I have mentored Django Girls just once, so this is just my single cent. :)

[keikoro]

I agree with you in that it's important to provide explanations, especially for complete beginners (which I admittedly wasn't when I took part in the first Django Girls workshop, like several others) and I also don't think the Django Girls tutorial is "perfect" in that regard (the last version I knew; I haven't worked through the most recent one!).

As you mention being first and foremost a Pythonista: it could actually be I like the tutorial so much (and better than the Rails Girls guides) because there's lots of "pure" Python in it as well. (:

In any case, I think creating something of your own, step by step, rather than working with/improving a project you're provided with is important for those who want to know what's involved and how to replicate and adapt this knowledge for own future projects (and it seems to me it's mostly the people who already have ideas for what they want to do with their newly gained knowledge who continue learning; I believe this is true for many activities, not just coding). This certainly was important to me.

Maybe there would need to be different versions for total beginners at everything and people who already know some things but are looking for instructions on how to work with Django specifically.

[spinecone]

Hello, I'm a coach from Portland, OR and have been reading these proposed changes because I like the idea of taking an academic approach to the way programming curriculum is structured. I just wanted to chime in by posting a section from the Django Girls coaching guide that really made clear to me how Django Girls is different from similar workshops.

"The ultimate goal of the workshop is not to build a website. It is not to teach the whole of Django. It is also not to teach programming. The ultimate goal is to show that code is fun. To get people excited. To show them that programming is not scary and that it is for everyone. To show them how powerful programming skills can be."

Before working with Django Girls, I was skeptical of one day workshops as a whole because I couldn't understand how or why you would try to teach someone so many different web development concepts at once. And ultimately I have decided that it isn't really possible, but that isn't the point of the workshop. If an attendee can leave the event feeling that they have accomplished something and that web development is something fun that they want to continue learning on their own, the workshop has been a success.

I hope this isn't too much of a diversion from the current discussion, I just wanted to point out that while it's important for the curriculum to make sense and to effectively communicate the concepts being taught, my understanding of the underlying principles of the workshop is that it's more important that attendees have a fun time and feel good about the work they do. When they have created an entire application from scratch, even if it's just by copying and pasting instructions they don't completely understand, it's a very real accomplishment which is more tangible than modifying a working application that is given to them.

That said I definitely think that lines like "add our new model to our database" make a lot of assumptions about what attendees have learned and can be reworked to be less confusing. I have also witnessed attendees having "too much fun" with HTML and CSS, but that kind of enthusiasm could be a great way to start off the workshop.

[zanderle]

@kerstin all the changes I talked about need to be taken with care. I believe the whole tutorial (not just the part about pre-made project) should be a bit more layered. Meaning, it should be first and foremost done with complete beginners in mind. However, since it's online and available for future reference, it should also contain the more detailed explanations. So for example. if we used a pre-made project, it should also contain all the steps required to get to that pre-made project. And maybe some attendees with more experience, would not even require the pre-made project in the first place...

@tpinecone I agree, and I think it's important to keep these things in mind when discussing big changes like this. You say

When they have created an entire application from scratch, even if it's just by copying and pasting instructions they don't completely understand, it's a very real accomplishment which is more tangible than modifying a working application that is given to them.

and

The ultimate goal is to show that code is fun. To get people excited. To show them that programming is not scary and that it is for everyone. To show them how powerful programming skills can be.

Are you sure that that is the case? I am worried, that by trying to forcefully explain everything in order to avoid magic, the attendees can get the feeling that this is too complicated. It ends up being scary, because it is unknown. Instead of creating on their own, they are copy-pasting something they don't understand... I know from my first experience to programming - if I copy-pasted something, I would not feel confident using that on my own in the future, if I didn't understand the meaning behind it.

[janezd]

@kerstin I like the idea about different versions. These don't need to be like completely different tracks, it can be on the level of individual lessons, for long as everything still fits together. This would allow the mentor to decide what to explain in detail and what to skip. (S)he can decide to go through configuration files line by line if the student plans to actually set up her site next week, or use a prepared file if student shows zero interest in setting anything up but would like to know more about something else. I would explicitly instruct the mentor to decide about the depth based on the student's interests and abilities.

Same for, say, Python. We could keep (some?) redundant material in the core part, but instruct the mentor to use it only if the student is really interested and if the time permits.

As a side effect, this would reiterate the message to the mentor that (s)he must observe the student and follow her interests.

[keikoro]

@janezd I like that suggestion, including the bit about Python. I, for example, already knew about types, operators etc. but liked the refresher on lists and dictionaries; I also think if/else is one of the concepts you'll want to learn about sooner rather than later if you plan on continuing with programming (regardless of language), so I'd find it sad if it got moved out completely.

I don't know what the newest version of Gitbook is capable of but something like colour-coded paragraphs would help with knowing what's the more "advanced" stuff (as not everyone, including at workshops, goes through the tutorial guided by a coach; some participants just work through it at their own pace and only check back with their mentor if they have a question).

[olasitarska]

Thanks everyone for the discussion here, so productive and helpful!

@tpinecone very good points with getting people excited.

So I think in general, we actually all agree that this proposal is good. One thing that seems to be a blocker, is giving a ready project. I still think that we shouldn't do that, because the gain is not enough. Although I think it's worth an experiment. Maybe we could create two versions: first pull request that would introduce all the other changes from the proposal, except giving a ready project. Once this is done, we can try experimenting on one of the workshops by deploying a second version of the tutorial on a different branch, to see the actual reaction of people.

I wouldn't like to include "optional" or "advanced" parts in the tutorial though -- I think our goal is to keep it as simple as possible, to make our maintainence easier and to not give too many choices and paths to follow to already confused readers. I think our strong part was so far trying to give one answer, no many answer people can choose from. Things like that would be perfect for extensions book though, that we're still trying to improve.

Does that make sense?

[zanderle]

Thank you @olasitarska and thank you everyone for your feedback.

I will start working on these changes shortly and create a PR, when I have something to show :)

[keikoro]

@zanderle, when you wrote
"The CV task was only meant (...) for tinkering with HTML (...) Maybe a static blog is better. Or a homepage to a blog, or something like that."
I was thinking that maybe an "About" page for the blog that gets built later on would make sense.

[zanderle]

@kerstin actually, my exact same thoughts, after reading the initial feedback about that part!! :) Totally agree!

[keikoro]

(:

[wdonet]

any update on this?

[zanderle]

Yeah. I was busy with other things so I had to put it on hold. Last week I started working on it again. I am currently working on a version without a premade project. Because of this change, a lot of the proposed changes had to be adjusted to accommodate that.

After that I will also do the version with a premade project (which is what I originally proposed).

You can expect updates/pull request in one or two weeks.

On 15 Jan 2016, at 23:38, Oswaldo Herrera notifications@github.com wrote:

any update on this?

—
Reply to this email directly or view it on GitHub.

[mikedlr]

To give some motivation to this, a friend of mine attended a DjangoGirls tutorial and came away completely confused and definitely negatively motivated (before that she believed she could do basic web dev - afterwards she believed it will take weeks of work).

Listening to her comments and reading through the tutorial, the work proposed by @zanderle sounds very much in the right direction. However, also it seemed that that she suffered from conceptual overload. She's never been a programmer so I think she's a perfect match to the target:

we want to show you that programming or creating websites is not as complicated as it seems

As a very simple example, there are things like the map of the internet which could be replaced very simply with a picture of a client and a server. You don't need to know that the internet has complex connections to be able to use it.

I wonder if a good approach wouldn't be to make a completely fresh start. Begin from the end goal and then only allow in material which is needed to reach that goal.

[zanderle]

@mikedlr yeah things like that were definitely the motivation behind this work. To be fair - web dev will take weeks of work. The idea is to show that it can be done, rather than being an impossible goal.

I think there's a fine line between wanting to show it can be done and not oversimplifying it. In my opinion, DjangoGirls is the closest hitting that line, but that doesn't mean it won't still take a lot of work and iterations to improve (hence, this proposal).

A fresh start is not a good approach in my opinion. In sounds good in theory, but there is just too much work to be done for it to be a realistic goal. I'm thinking of how long this is taking me, since I'm only doing it my free time (and this is far less work than a completely fresh start) and comparing that to starting from scratch.

In any case, thank you for providing more motivation :) That's always helpful!

[mikedlr]

Hi @zanderle; thanks for such a quick great response. I think I failed to be clear enough by what I mean by a fresh start. I don't mean through the material away. Instead, I mean take a fresh empty document then selectively copy in existing material to that.

Copy over into that document the minimum to sensibly achieve the goal of "creating websites" whilst making sure that the people following the tutorial can explain what they have done and ask for help (that would be my definition of "not oversimple").

The rest of the material doesn't get thrown away. Instead it goes towards part two (or three or something). These parts could even be run once the first part of the tutorial has been achieved. I think that it's basically what you are doing but with maybe an approach more oriented to making the initial web application easy to complete for sure.

[zanderle]

@mikedlr I see. I misunderstood :) Yeah, it's what I had in mind when writing this proposal (and it's something I keep thinking about)- let's not explain what we don't need to. So some stuff is already planned to be "thrown out" (more accurately - moved to Extensions). Most of the tutorial is fine though.

It's also important to keep in mind that attendees come from different backgrounds and are at different levels when it comes to programming and web dev. So in a way, the tutorial will always be a bit too much for some and a bit too little for others.

If you have any other suggestions about this proposal, please let me know.

[janezd]

What DjangoGirls achieved is amazing. It's a great project. Yet I shared the same frustration as @mikedlr 's friend, except that I was in a role of a mentor. I could either explain stuff (and skip three quarters of it) or rush over it (and utterly confuse and discourage the three girls I mentored). The last time I tried something in between, I failed, and I decided to not mentor again.

Perhaps it is crucial to set a reasonable goal. Learning how to create a web site cannot be sensible achieved in a relaxed one-day workshop. We're giving the participants a false promise. The goal is probably that the participants get a taste of what creating a web site looks like, see that programming is fun (most of time) and that they can learn it (in a few months or years).

The style of the tutorial is great, it would be a shame not to use it. We just need to decide what we want to achieve, and rearrange and trim the material accordingly.

[zanderle]

Slowly battling through the proposed changes. You can see the progress here.

There is still a lot to be done. If anyone is willing to help out, please let me know :) I'd love to push this forward more quickly, just don't have as much time to work on this as I'd like...

[zanderle]

Yaay, progress! I think we're getting close to getting this ready for PR. I just hope there will still be interest in merging this :) ( @olasitarska , @patjouk ?)

If anyone would like to help, please let me know! I'll gladly explain what needs to be done.
Here's a list of things that we need to get done before creating a PR (details are in TODOs in the files, or just ask me directly):

• Rebase -- @zanderle
• How the internet works: simplify and add context -- @ialja
• Introduction to Python: simplify and reorder -- @ialja
• Django: simplify -- @zanderle
• Django views: css is not in the right place -- @EmilyK
• Django Models: add context and drop OOP -- @souravsingh
• Django ORM: add context -- @souravsingh
• Dynamic data in templates: add context -- @zanderle
• Extend your application: introduction that relates to previous chapters
• Images: a lot of images need to be updated
• Proofreading and editing -- @kerstin
• General overview of the tutorial: did we miss anything?

[souravsingh]

Hello @zanderle, the idea looks really nice. Please let me know how I can help.

[zanderle]

@souravsingh any of the bullet points that don't have someone assigned already (see my previous post). Let me know what you're most interested in helping out and I can explain anything that's not clear. We can also chat on gitter or irc if necessary.

[souravsingh]

I can work on the Django models and ORM.I would like to know what needs to be done in "add context"?

[keikoro]

It's not part of the TODO list, but I'd volunteer for proofreading & editing when each part is done.

[zanderle]

@souravsingh awesome, thank you! What needs to be done in add context? The order of the tutorial has changed in this PR. That means that the introductions and endings of specific chapters don't make enough sense anymore. So add context simply means: make the chapters follow the new order of the tutorial -- read the previous and the following chapters and make sure that things make sense.
Also, in the Django Models there are some other TODOs. If any of them don't make sense, please let me know.
In the ORM chapter it would also be great, if we added a short explanation why we will need .filter() and .all().
See my fork for all these changes (on branch feat/without_premade_project).
@kerstin awesome, I will add it to the list and ping you when necessary, ok?

[zanderle]

@patjouk would it be possible to add "help wanted" label on this issue?

[keikoro]

@zanderle Sure! If other people want to help with that, that'd be cool too. Could be split up into e.g. general readability and tutorial contents (form vs. logic).

[patjouk]

Hi @zanderle. Thanks for your proposal :)

Just a few things to keep in mind:

• we have now 13 translations of the tutorial. Any big changes will ask a lot of work to translators.
• I read this blog post yesterday and I think we should be really careful of not oversimplifying and removing too many parts.

I'm wondering if this could be used as an upgrade tutorial (issue #341): a lighter version to redo the tutorial after finishing the first one.

We'll need to discuss all those changes (a meeting with organizers and the Support Team?). Right now, most of the Support Team is working on Django Under the Hood and won't have time to take a look at your changes. We will try to discuss it during the sprints but we already have a lot on our plates.

[zanderle]

@patjouk thank you for taking the time!

we have now 13 translations of the tutorial. Any big changes will ask a lot of work to translators.

Yeah, that's been in my mind from the very start. That's why I tried to do as much as possible with just changing the order (so, same content), and adding as little as possible (again, to keep the existing content). That should keep the translators' work to minimum.

I read this blog post yesterday and I think we should be really careful of not oversimplifying and removing too many parts.

The proposed changes are also very careful and mindful of things we want to remove/simplify. There are only a couple of things I propose to drop and everything else is just moved around (so neither dropped nor simplified).

I'm wondering if this could be used as an upgrade tutorial (issue #341): a lighter version to redo the tutorial after finishing the first one.

The whole point of this proposal is to improve the existing tutorial with established teaching practices. That should provide a better experience for the students as well as mentors. The intention is, that the students would get more out of the tutorial, not less.
But yeah, unfortunately, these are not simple changes as the tutorial is big.

We'll need to discuss all those changes (a meeting with organizers and the Support Team?)

When discussing the changes, here's the original proposal with the comments: google doc
The changes here are only the changes where there was consensus (so that means no premade project, no CV, and some other bad ideas :) ).
And please let me know if you'll require my input anywhere in the process. I'll be happy to help!

Thanks :)

[patjouk]

The work for translators won't be minimum. Our translation process is broken and we're trying to fix it. I would recommend checking our Translation Guide to see how much work deploying a translation required. Even if it's just reordering, it will require validation of the moved parts, translation of new ones, proofreading, adapting the markdown to Gitbook and deploying.
Plus, we're not guaranteed that people who worked on the previous translation will come back to do this new work.

[aniav]

We will try and discuss it during Django Under The Hood or during next support meeting. This topic is not easy from our point of view even if it's just reordering so we need to think it through and decide if and how we want change the tutorial :)

In the meantime @zanderle you are doing great work and this is such a huge effort 🎉

[zanderle]

@patjouk @aniav I understand that. This is quite an undertaking and a lot of work is involved. What I meant was merely that I tried to keep the content changes to a minimum. Still, as you said @patjouk , this is nevertheless huge.

I understand your point of view and your reservations about all of this. At the same time, as someone who is interested and fascinated by the field of pedagogy, improving the tutorial from a teaching point of view is what I'm trying to focus on. I'm not ignoring other aspects of all of this, but I am trying to make a case for improving the tutorial.

I would hate to see that the translations would prevent this tutorial from being improved.

In any case, I am certain we can meet halfway. I'm here to help you make this as easy as possible for you (DjangoGirls team), while at the same time make sure the changes still keep their initial intention - make the tutorial better for everyone. So, please keep me posted and let me know how I can help :)

[SambhavS]

Hi, I'm not a contributor but I just finished the tutorial and happened to find this thread, so I thought I would give my comments on the pacing. As someone who has completed APCS, done some competitive programming in Python, some minimal prior experimenting with Django, and some small personal/paid web dev projects, I found the pacing to be a good match for me and it took me 4-5 hours to finish everything. So, I think a one day workshop would be good for high school students with a nontrivial amount of programming experience. For complete beginners of reasonable capability (e.g. not MIT students), I think that it would take at least a week to be able to go through the whole tutorial and understand the majority of it. I found the material to be mostly well written, easy to understand, and non-ambiguous and had more fun than I usually do when completing these sort of tutorials.

[zanderle]

@SambhavS yea, I agree. But maybe that's intentional? In any case since the last update, I haven't done any more work on this, since there was no update from the DjangoGirls team. I'd still love to work on this and improve the already great tutorial. But I am not sure that these changes are aligned with their current goals, so I didn't want to keep working on something that won't be used anyway.
Which is why I'll close this issue, and then if the need arises, we can always reopen.

[keikoro]

@zanderle Sad to hear that (was wondering myself what had happened to this project when the new comment got posted) but totally understandable.

[ekohl]

Somewhat related: #1085