Hellos,
On Fri, Apr 24, 2009 at 10:06 PM, <m...@sysfault.org> wrote: > René Dudfield <ren...@gmail.com>: > > hi, >> >> very awesome of you to go ahead with this... >> >> I read through your website... and it's got some good ideas... >> >> It'll be cool if we can make pygame one of the best sites around in the >> python scene again... the current one is from around 2005... and has been >> really good so far. >> > > Well, the colours started to hit some nerves for me, so it might be better > to go with some pastel colour palette for the new one :-). > yeah, perhaps. We should probably have the graphical design as a separate step. So we can choose the best design made available. > > > Rewriting the current functionality in python first could be a good way to >> go. Once the current site is replicated, then move on to other stuff. >> >> All the old stuff needs to be written at some point... because we need to >> keep all the old urls around (including feeds). Also it's easier for >> people >> > > Is there a way to have some easy to manage URL rewriting/forwarding in > Django? That way we could let existing URLS resolve to the new stuff (e.g. > place the currently static html sites into the DB and link to them). > Almost all web toolkits have decent url schemes, and rewriters. It can also be done at the apache, and wsgi levels too. The current website has a pretty good system... where it uses a database of rewrite rules editable through the web in the management system... but we can easily use mod_rewrite or whatever we need. I don't think we have agreed on Django specifically yet. At least pymike, and I have suggested using cherrypy. Also I know Nicholas has made the last few websites he worked on with cherrypy. So we should decide this based on what the contributors to the website feel is best, and also the people who will maintain it. > > to work towards something that exists, rather than working towards a new >> design. >> > > A new design is necessary in my opinion. Colours, overall style, etc. > The functionality though needs to stay the same (with improvements all over > the place). > Sure, but that can happen after the current one is updated. It's much easier to make design as a separate stage. So when reimplementing it we have the current website as a reference. With a new graphical design coming afterwards(or designed separately in parallel). > > >> First steps are to agree on a way forward... but if we go with remaking >> the >> existing site... we could follow this path: >> >> - prepare html/php/sql from old site. >> - get old site running outside of the main pygame.org so people can test >> it >> easily. >> > > The current one is already around and was widely tested. Or do I miss > something here? > Yeah, that can be used for lots of things... but not all. So as to test things without messing up the main website... eg adding projects, wiki pages, news etc. Maybe we don't really need to do this... and can just look at the code mostly. > > > - decide on which tools we are to use. The main ones from people >> interested >> seem to be a django, or a cherrypy based site. >> - start writing the models for the various tables, and data types in >> existing site (eg, project, user, wiki page, etc). >> - collect a list of existing urls. >> - collect a list of existing functionality. >> - collect a list of html/php pages to convert to templates. >> - start working on list of functionality, and templates until it is >> complete. >> > > Sounds good to me. Though I'd go with the existing functionality first. The > existing URLs and such are things to be considered for a final migration. > Thus I would move this to the end: > > - put site up for people to test on a test domain.... eg test.pygame.org > - work out migration plan: > - migrate projects and static content > - add functionality for eixsting URL handling > - replace existing website on pygame.org, and make sure it works ok. > - END. then can work on adding new stuff. > > Otherwise it might easily happen to limit the new system in some areas due > to > the existing structure. > > Working out the migration can happen in parallel to the test phase. Letting > people test is nothing, which should keep you on a 24/7 work load, so while > anyone plays around with it, you can work on the necessary conversion > system. > Yeah good point. We will need to make sure the existing data can be put into the new website at some point. It can be easy to take the existing database and just use that. This is quite easy to do with things like sqlalchemy and the like. So to decide which way we go, we should study the database structure to see if it is ok. Migrating the data is probably easiest if we use the existing database directly. The wiki code is mostly html, so isn't that hard to convert. > > > Also, is it possible to do this at google code instead? >> http://code.google.com/p/pygame/ >> > > Sounds reasonable - google already has the whole functionality for the > project, > Julian currently hosts privately. It might be good to use google's wiki > there > and a seperate website SVN branch. Especially since the final system could > be > adopted by other community-driven projects. > > Also lots of people already have google accounts on there, and it's not hosted on someones personal server. Keeping it separate from the main pygame svn makes sense, since it's probably going to be a separate group of people, and also it's fairly easy to allow access to it.
