Sign me up to help, please.I would like to humbly vote against using github or anything similar to submit games. I think there should be a dead-simple web interface.Yes making a pull request is easy for you and me, and yes I think that all game developers need to learn github sooner or later, but there are many people who are not there yet, and I think it needs to be as easy for them to use pygame and share their results as possible.Obviously pygame is never going to be powering AAA games, but it's excellent for beginners. In order to fill that niche and remain relevant, however, there need to be as few barriers to entry as possible.However I will concede that anything is better than the current setup.On Fri, Dec 16, 2016 at 5:21 AM Radomir Dopieralski <pygame@xxxxxxxxxxxx> wrote: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 <takowl@xxxxxxxxx> 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!
--
Radomir Dopieralski