I'm on-board with redoing the website like this document lays out. I can contribute some hours. Not lots of hours, but some.
I think one of the popular static content generators would be great. First glance, Nikola seems ok. If Daniel is able to get it started, that would be great. I think it would be nice if we could smoothly integrate the API doc build with the static part of the new website. Or Jekyll. I don't know these systems well enough to have an opinion, but I like the idea of making the site in simple markdown format, and allow people who want to contribute to do so with GitHub. My programarcadegames.com website has a ton of examples I'd be happy to de-brand and make available. If there's any interest in that, I could help with the example part of the website? As a wild stab, what about hooking a Reddit feed for the recent games? Use reddit admin tools on reddit, and then pull in the feed and format nice for the website? I feel like for help, the Reddit forums might be more useful than specialized website forums. Paul Vincent Craven On Thu, Dec 15, 2016 at 2:29 PM, Daniel Foerster <pydsig...@gmail.com> wrote: > A Python competitor with Jekyll that I've used and might be found useful > is Nikola (https://getnikola.com/). It accepts things like markdown, > ReST, HTML, and plaintext as input and has support for a number of > templating engines, including Jinja. If we were to go that route, I have > access to a pretty clean template that we could use. > > On Dec 15, 2016 14:24, "Thomas Kluyver" <tak...@gmail.com> wrote: > >> Hi all, >> >> I know several people on this mailing list have proposed overhauling the >> Pygame website in the past. Now's your chance! >> >> The current Pygame website contains outdated information, relies on a >> (not so) secret sign up link for people who want to submit games, and as we >> can't currently contact René, we don't have access to change it. Peter >> Shinners, who registered the pygame.org domain, is on board with >> building a new site and making it pygame.org. >> >> The first steps are assembling a team of people who're interested in >> working on the website, and working out what technologies we'll use for the >> new site. I think the best way to tackle it is as two separate components: >> the static information and the game feed. I've copied in more details about >> what I think we need at the bottom of this email. >> >> If you're interested in helping to build this, or you have ideas about >> how best to do it, please reply to this email! >> >> Thanks, >> Thomas >> >> ----- >> Details: >> >> General info: >> >> - >> >> Designs, mockups and prototypes are welcome, but please don’t spend a >> lot of time building anything yet; we might go for another option. >> - >> >> Assembling a team to build and maintain the site is an important part >> of this. An average architecture with several people happy to maintain it >> is better than a genius architecture with one quarrelsome maintainer. >> - >> >> I’d like to preserve the informal, playful feel of the old green & >> yellow site, so bright colours and cartoonish graphics are acceptable (but >> not required, if you want to go a different way). >> >> >> Part 1: Information >> >> - >> >> Information about the project, how to install it, links to >> documentation & support forums, etc. Including content from the wiki on >> the >> old site. (Craven: Based on analytics for a different site, I recommend >> putting the following on the home page, in this order, quick links: >> Example >> code, installation instructions, API docs, projects that use Pygame.) >> - >> >> This part should be served as static HTML: solid free hosting is >> available for static sites, and we don’t want to worry about the security >> of a dynamic web application. >> - >> >> The HTML should be generated from content and templates stored in >> public version control, to allow easy collaboration. >> - >> >> Tools: there are many static site generators. Jekyll has a head start >> as it’s built into Github pages, but we’d consider other options. We’d >> like >> building and deploying the site to be automated, and it should be easy for >> contributors to build the site locally to check their changes. We have a >> slight preference for Python-based tools because contributors are likely >> to >> already have Python. >> >> >> Part 2: Game feed >> >> - >> >> An up-to-date list of recent games, with screenshots and links. Game >> developers should be able to add their own games to the feed. >> - >> >> It must not be possible for user-submitted content to hijack the site >> (e.g. by injecting script tags) >> - >> >> We need to keep spam minimal, without making too much work for either >> developers submitting their games, or the site maintainers. E.g. we might >> use CAPTCHAs and nofollow links. >> - >> >> If the game feed breaks, the information site should still be >> available. >> - >> >> One obvious way to do this is with a small web app and a database to >> hold the content. That’s possible, but it would need hosting and >> maintenance. Are there other ways? What external services could we use? >> Get >> creative! >> >> >> >>
