Hi, great news, I would love seeing pygame.org rocking again!
sphinx is new for me, but I am not the typical pythonean, could be intresting to learn. My personal approach is quite similar for the same goal wich is near zero maintenance: - static html-frame and css + markdown-text-files, these get directly linked and if javascript is enabled: translated into html, done by jQuery and showdown. Best regards Enrico Am 16.12.16 um 11:12 schrieb Radomir Dopieralski: > Hi, > > I would be happy to help. I didn't get involved much in the previous > efforts, because I didn't think they were the right way to do it, but I > am all for a low-maintenance, simple, static website that won't get old > fast. > > As for the tools, I wonder if we could just use Sphinx like all the > PyGame documentation does, and not get extra tools involved. We will > need to make a custom Sphinx theme anyways, to make the documentation > look and feel match that of the rest of the website, and once we have > that, we can as well just use Sphinx for all the rest. This way it will > all be done with the same markup and using the same tools, and if any > Python programmer doesn't know Sphinx yet, I think it's only a good > thing to have to learn this tool, as it is pretty much a standard in > the Python community. I did that before with Sphinx for at least two > projects, and I can say that it's doable, even though some of the > extension mechanism that Sphinx offers for doing custom stuff are not > the most convenient. > > As for the list of games, I wonder if we could just make people commit > their entries into a github repository, together with an image and > description? I mean, this is interface for people who are making games > already -- so we don't necessarily have to make it super-easy and open > to spammers. Github has their own anti-spam measures, we could take > advantage of that. This way we avoid the need for a custom database and > app hosting. We can just generate static html for the game list daily, > or from a github hook. > > What do we want to do with the wiki? Do we want to "migrate" it to some > other engine, or just leave it as it is for now? Maybe put it into > github wiki too? > > > On Thu, 15 Dec 2016 20:23:50 +0000 > 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! > >
