Not an issue, unless you hate Python.

[chorn21]

We started to Django-ify (...) the website. It's looking pretty sexy. Thankfully, Reed and Bhargav are at least slightly above mediocre at teaching. Just giving everyone a heads up :D

[dylnuge]

Has anyone discussed this with the people who made the decision to bring down ConferenceWare?

I highly vote against using Django for this project. It's not needed at all, and will over-complicate things.

What are the reasons for considering a move to Django?

[jtfairbank]

We're integrating the Conference website with the new ACM site that Reed is working on, to keep things consistent.

It shouldn't really over-complicate things- if anything, Django will make maintaining the conference website easier due to its ability to store common parts of each page in one template.

[reedlabotz]

What we want to do is use django for the development so we can easily make changes during conference. For instance adding speaker bios, changing the schedule, ...

I am going to write a script that will convert the entire site to static html so that we can easily archive the site after conference. This should make it so we don't have the problems we have had with conferenceware incase we drop django anytime in the future.

[dylnuge]

There are static site compilers and templating engines. I'm working on my own right now (dylnuge/siteseer). Simple template stuff should not be done with a web application.

And I don't see how it will be integrated with the main ACM site, can @jtfairbank or someone else explain that further?

[dylnuge]

@reedlabotz Archiving the site in static HTML is a good idea, that takes away some of my concerns. I still don't see how using Django will simplify updating things any more than a static site.

Using Django raises the knowledge barrier to entry for the website project at minimum. It also risks creating something poorly documented that no one knows how to use after the creators graduate (see ConferenceWare). I'd be interested in hearing @bnookala's thoughts on this, since I believe he made last year's site after choosing to move off conferenceware.

[reedlabotz]

We want to make it so that when you are in intranet if you are on conference committee you will be able to go in and edit the speakers and what not. This should make their lives easier so we don't have to worry about people editing the html.

If we can take a snapshot once conference is over this shouldn't cause any problems for admin in the future.

[cmr1347]

Totally don't know enough about how this works to have an opinion either way, but my biggest fear about integrating the websites more is whether that means that changing either website in future years is going to be a pain in the ass. Is this something to be worried about or are all the connections between the two easily reversible?

[dylnuge]

I'm not super concerned about archival. My main concerns are:

• This is over-engineering the conference site. I know we're all software developers and we love doing web apps over static sites every time we get the chance, but I just don't see this as needed in any fashion.
  • I assume this is going to be reusable. If you make something not reusable, there's literally no reason at all to make it.
  • Tools exist to cover most of what you want to cover. Wiki features aren't needed with a simple model for the site to pull from a release branch every night. I've already mentioned site compilers.
  • You're planning on converting it to a static site after conference, which is complex.
• You scare away anyone who doesn't know Python (and possibly Django) well:
  • Even if you have no knowledge required to join web team, this means you have to teach stuff. Most people will leave if they don't pick it up immediately.
  • We may lose the less technical people, who we would like to have for a lot of reasons.
• There is the obvious issue that we haven't even gotten Liquid to work on ACM systems yet. Static sites are more portable--they pretty much run everywhere.
• You place the burden on admin to make sure the site is running, is secure, and is stable. There is a reason we don't let any ACM user just run dynamic sites on the cluster.
• If you make something that is reusable for every year's conference, it will follow in the footsteps of conferenceware unless beautifully documented. This is, of course, difficult to do during development on the conference timeline, and usually no one does it afterwards.
• Static sites are faster, easier to cache, easier to set up, and pretty damn hard to break (short of breaking the server with a DDoS or something similar).
• Django isn't being used because it is the right tool for the job, it's being used because it's cool.

Obviously, I'm not on the conference web team. I can assist where needed, but I don't plan on officially joining the conference web team. My opinion is simply advice here. I will not and can not stop you from doing what you want with the site.

I would take all this under consideration, and really think about whether or not you are using Django because it is actually a need to make the site dynamic, or if you just want to use Django because it's fun and cool to make Django websites.

Basically, I think this is a poor decision being made for the wrong reasons.

[dylnuge]

@cmr1347 I'm not sure what @reedlabotz and @jtfairbank mean by integrating the site with the main ACM site. Other than a link from ACM to conference, I cannot see any way the sites would be integrated. Unless they just mean using the same users database to login to the conference site, which is pretty much a given. Sharing a users database shouldn't cause an issue in difficulty of updating either site.

@reedlabotz I would also like to point out that making a wiki-style page editor is not easy, could open security holes, and is insufficient for people wanting to change things like stylesheets. I don't see why the web team can't just make changes to the static site as they have been doing already with github. I can help you set up a remote on the ACM servers that pulls from a release branch on github and stores into the proj.rp.www AFS volume if pushing the site is the main concern here.

[cmr1347]

So question: since the conference site is still seeing a lot of revisions and needs just about all its content and a lot of design work done, and liquid hasn't even been launched yet, would it be possible to put django on hold until we have something up that we're happy and proud of? There's nothing wrong with you guys putting your own time and energy into doing something that interests you that could make the sites better, but completing the most basic stuff necessary to set up all the parts that the public sees has to be the main priority.

[chorn21]

I would just like to add that nothing has been pushed/merged yet; everything that has been changed is all just locally on my machine as of now. So technically it's like it doesn't even exist yet, if that makes you guys feel better...?

[jtfairbank]

I agree with Dylan that Django is not the only solution. However, I will say that in my opinion it is not a bad choice either. The flip side of the coin to "people being scared off b/c they don't know Django" is that we will attract people who do know Django and that we offer an opportunity to learn Django (as Caroline is doing).

I also agree with @cmr1347- we should probably focus more on other parts of the site. That being said, I think that getting basic templating up (through Django or otherwise) is going to be very helpful in developing / modifying / maintaining the site until after Conference.

Finally, I think that having some sort of CMS, whether it be wiki-style or not, is a good thing. There will be many more people who will want to add content to the Conference site in the upcoming 6ish months, and it makes it easier for everyone if they can do that themselves (less complicated content addition process).

I'm not being very definitive, just throwing out some things to think about.

[dylnuge]

I've talked this over further in person with Rob and @reedlabotz and come to the conclusion that if you are building something versatile, reusable, and with some great functionality for more than just a yearly website (such as the previous speakers log I heard mentioned), then it's probably fine to use Django.

I'd recommend maintaining the fully working static version of the site alongside the Django development.

I'll also point out that I'm still working on all the BS needed to get Django sites running on the cluster. Does anyone want admin to set up the site to auto-pull from master for the time being?

[dylnuge]

Update: Admin now supports Django, but can only support a single Django instance running on the main www servers (all Apache misses are passed to Django for match or 404). The site therefore should be a project pluggable into the current Django site.

[jtfairbank]

So @colegleason ended up going with a PHP setup- Imma close this issue.