We need to have people who are submitting a miniconf proposal agree to
releasing the material. The easiest way to do this is to just make it a
proposal like the other two types. We don't have audience type for
miniconf, instead of deleting it just have a default - it's easier.
WARNING: This requires a real migration to be performed before use.
Update the recording and materials release to say Linux Australia, not
Pycon Australia. This generates a migration because the model text has
change - but also because in the 0001_initial migration it appears that
this help text is stored as a byte string.
This is a bit weird, but realistically running this migration is not
going to cause us any problems so just add it so we don't end up
fighting django along the way.
Link to the T&C and Code of conducts so people know what they are
accepting. Create this as a static link because i don't know how django
would accept this being something dynamic on the model.
This annoyingly creates a migration, but it's not a real change and
easier to accept it now than fight django forever.
This app is now python3 only so we must specify python3 when creating a
virtualenv. Yes this assumes that most people are using python2 as
default, most distros still ship this way.
The site requires you to have some basic data installed in your database
before running. This is located in the fixtures file and so the README
should tell people to install this data.
We're lock step with this, we're installing with master.
Upstream is dead.
We can't roll back.
It doesn't make since to pin to every commit and revision our apps
version and push it.
We're just going to pull this in to gain full lockstep and call it good.
Drop markdown for monospace
With markdown, we're only allowing about 1/10 of what is possible.
This creates a false reality and expectation. Lets not suggest this.
Nor do we have in-editor preview. So the user has to save, look at it,
then go back and edit. And seeing a bunch of sanitized HTML or just
missing sections isn't firendly.
Monospace, what you type, is what you're going to get. It gives the
presenter enough power to build a readable abstract, but not so much
that they can break the page and it's CSS, nor the ability to confuse
onselve through not getting what you expect.
We keep bleach sanitation and we should probably run linkify on this in
the long term. (Turn links into clickable links)
DEBUG is something that should never be turned in on prod. As such,
lets be extremely specific on what we expect to process.
As we'll be taking this in from the environment, it's ensured we will
get a string. So we'll always get and only handle this in string
form. If it's anything else, it's an operational error and we bail.
(Note: bool('0') is truthy, so we make sure we leverge our string -> int
-> bool every time, so corectness can be noticed if it is not)
