Forums

I'm thinking of setting up a class using PythonAnywhere, I'd like to pre-populate the account with some material but let them keep it afterwards. Has anyone done this, any ideas how?

Hi Andriod!

One day we're going to release a whole host of awesome features for people running classes on PA. One day. But for now...

How about a github repo? Then they can just use git clone to get started, it's a simple single-line command to cut+paste into a bash shell.... if they're developers, even better, they can fork + punctuate their progress with commits

It would be nice to hear about "whole host of awesome features for people running classes on PA" in detail?

I'm very interested in such features too.

We have some ideas along those lines, like creating student accounts that are pre-populated with the prerequisites, consoles that are automatically shared with the teacher, and so on. We'd also love to hear any ideas you might have that would help you if you're using PythonAnywhere for teaching.

Disclaimer: I'm not using it for teaching, but I was just trying to brainstorm about this...

Sounds to me like at least some of those features could usefully be slightly abstracted into "account groups", a little like Github's organisations. So users can create a group and then invite other accounts into the group. Looking at this generally, it could be suitable for corporations and open source projects as well as teachers.

To me the main difference with this would be that instead of student accounts being a special type of login, you flip it round so any account can be a member of one or more groups. Existing accounts could be placed into special "solo" groups which only have a single member, which allows everything to be kept under this group abstraction (hopefully reducing special cases in the configuration code).

Perhaps this might make account management easier for you guys as well - each group would have a "class" indicating its resource limits, which could either be shared out among the group members or copied to each instance (I'd favour the second one - sounds like a way to get around resource limits, but in reality it's no easier than simply creating tons of dummy free accounts, which is already possible in principle). So, you could have a cheapish account for teachers with strict resource limits per student, and a more expensive account for companies where each member of the group gets more resources.

The UI for this could be tricky to get right, but as a first stab perhaps an additional row of tabs above the existing ones in the dashboard would be good. So, each operation is inherently scoped to within a group. If this additional tab row only appeared when needed (i.e. if the user was a member of multiple groups) then there shouldn't be any visible change for existing users. Also, students could create accounts which weren't members of the "solo" group so they could only use the teaching group account - this should keep things simple for them until they understand more about how to use the site. It also allows students to create their own accounts so the teacher doesn't have the tedium of creating their accounts for them.

The template filesystem layout could be attached by the group owner, although I do believe this should be copied in only once at initial group joining time (and probably at a later time at the user's option to revert their entire filesystem back to the template, with a suitable warning that all their stuff will be irrevocably destroyed).

The automatic console sharing could occur only with the group owner, or between all members of the group, at the group owner's option. Either way, I don't believe this should restrict explicit sharing with other users, although perhaps the group owner should have the option to disallow sharing of group consoles with users outside the group. In UI terms I'd see there being a list of consoles shared explicitly with the current user (which could be from any group) and separate per-group lists of automatically shared consoles. UI for this might need a little thought.

If you want to allow SSH access for group member accounts, you could have something like username+groupname for the SSH login, with the user able to specify their "default" group if they don't append that (for standard accounts this would be their "solo" group).

To avoid the group owner having to send invitations to each member as their accounts are created, you could have an additional option which is to send an invitation to an email address which contains a single-use authorisation token (a random 256-bit hash, say) to join the group, valid for 5 days or something - clicking this link will take them to the standard account creation screen with the exception that they're automatically enrolled in the appropriate group (and not enrolled in the solo group).

Hm, that was a little stream-of-consciousness, I'm afraid. Hopefully I explained my thinking clearly. I think arranging things this way might be more work, but perhaps there's a way to implement a limited version which allows the teaching group use-case whilst allowing future expansion to allow other group types (for corporates, open source projects, etc.).

In any case, hopefully there are some potentially interesting ideas in that lot. I'm certainly not trying to claim I've designed your feature for you (^_^), it was just an interesting exercise to imagine how such a thing might work.

Groups are great, potentially a more general solution, but I imagine one that will take a long time to cover the needs of a class. If I'm teaching class/workshop I have a number of differences from other groups:

1. If payment is going to be made the school would pay for all the accounts initially then the students would either convert them to free or take over payment.
2. The school/instructor might not have e-mail addresses or even names when they setup accounts, or not want the students to get e-mails/access their accounts when initially created.
3. The school/instructor would have administrative rights over accounts, at least until they are issued, perhaps for the length of the class, probably they need to reset passwords just to keep the class going.

Thanks for the input Cartroo and Andriod. Our current thinking has been very much along those lines. And we were thinking a minimum viable first step was to create (actually just extend really) the concepts of groups so that we could give a user/s full rights to a group of accounts and then build additional features on from there.

+1 vote for groups

Thanks! Noted.