Re: [pygame] New pygame.org website

2016-12-27 Thread Thomas Kluyver
On 26 December 2016 at 18:49, René Dudfield  wrote:

> The download page can be updated with the same admin interface that
> someone managed to post news with. There's currently 6 users able to edit
> it... so I guess one of those did it. I added Paul and yourself now as
> well. See this issue on 'the website needs updates':
> https://bitbucket.org/pygame/pygame/issues/204/ Updating news, and
> community management is definitely a role which is useful, and needs to be
> shared amongst a few people. I'll track the 'make document of admin people'
> work in that issue.
>

Thanks! I don't see any admin link, though? Is there a special URL I need
to go to? My username on the site is takluyver, just in case you've given
admin permissions to another account.


> The open issue on the topic of dynamically generating the downloads page:
> https://bitbucket.org/pygame/pygame/issues/152 This needs a jinja2
> template, and a script which iterates over the 'downloads' repo. I'd
> suggest basing the html on the existing html. Whilst there are better
> layout options, that would be pretty easy to do for now, and is familiar
> for existing pygame downloads page users. There are more details to
> consider of course (like making an actual downloads repo and moving
> existing files in... and meta data for the files).
>
> There's been a couple of efforts to move the wiki into version control.
> There's even a wiki in the bitbucket version control, and scripts to
> convert the html into markup formats that bitbucket supports. (there's an
> issue open on this topic). However, in practice, way less people
> updated it without a gui (Yes, even markdown and rst is a turn off for
> quick edits). Pointing them to the bitbucket interface also meant very few
> edits. I think it was 5-10x less edits. Furthermore even requiring a login
> means 5-10x less edits (100x if you include the deluge of spam). When those
> numbers are multiplied together... it meant a tiny amount of wiki edits
> were happening. Then the bitbucket wiki started getting spammed to hell,
> but we didn't have tools to moderate it. Along with the edits dropping
> close to zero, I moved things back to the website wiki. But now there are
> pretty good web gui tools for markdown. Here's the issue on the wiki
> topic... but it needs a lot more thought on the topics of spam and ease of
> use. https://bitbucket.org/pygame/pygame/issues/153/wiki-website-
> generation-from-wiki-repo
>
> Burn out for the website admins, and website defacement because of spam
> means that a workable solution for spam prevention needs to be in place
> first for any wiki replacement.
>
> Keeping the existing game data for me, and a lot of project authors is
> very important. For me the main purpose of the website should be to help
> people making games have a community of makers. Showing your work is often
> one of the only rewards for making these projects in the first place.
> Seeing people upload their game to a website for the first time, I always
> see a grin on their face.
>

OK, it sounds like we'll need to build on the old site more than creating a
new one, then. What is available on the server (e.g. Python version)? Could
you give other people SSH access to it?

Thanks,
Thomas


Re: [pygame] New pygame.org website

2016-12-26 Thread René Dudfield
hi,

The download page can be updated with the same admin interface that someone
managed to post news with. There's currently 6 users able to edit it... so
I guess one of those did it. I added Paul and yourself now as well. See
this issue on 'the website needs updates':
https://bitbucket.org/pygame/pygame/issues/204/ Updating news, and
community management is definitely a role which is useful, and needs to be
shared amongst a few people. I'll track the 'make document of admin people'
work in that issue.

The open issue on the topic of dynamically generating the downloads page:
https://bitbucket.org/pygame/pygame/issues/152 This needs a jinja2
template, and a script which iterates over the 'downloads' repo. I'd
suggest basing the html on the existing html. Whilst there are better
layout options, that would be pretty easy to do for now, and is familiar
for existing pygame downloads page users. There are more details to
consider of course (like making an actual downloads repo and moving
existing files in... and meta data for the files).

There's been a couple of efforts to move the wiki into version control.
There's even a wiki in the bitbucket version control, and scripts to
convert the html into markup formats that bitbucket supports. (there's an
issue open on this topic). However, in practice, way less people
updated it without a gui (Yes, even markdown and rst is a turn off for
quick edits). Pointing them to the bitbucket interface also meant very few
edits. I think it was 5-10x less edits. Furthermore even requiring a login
means 5-10x less edits (100x if you include the deluge of spam). When those
numbers are multiplied together... it meant a tiny amount of wiki edits
were happening. Then the bitbucket wiki started getting spammed to hell,
but we didn't have tools to moderate it. Along with the edits dropping
close to zero, I moved things back to the website wiki. But now there are
pretty good web gui tools for markdown. Here's the issue on the wiki
topic... but it needs a lot more thought on the topics of spam and ease of
use.
https://bitbucket.org/pygame/pygame/issues/153/wiki-website-generation-from-wiki-repo

Burn out for the website admins, and website defacement because of spam
means that a workable solution for spam prevention needs to be in place
first for any wiki replacement.

Keeping the existing game data for me, and a lot of project authors is very
important. For me the main purpose of the website should be to help people
making games have a community of makers. Showing your work is often one of
the only rewards for making these projects in the first place. Seeing
people upload their game to a website for the first time, I always see a
grin on their face.





On Mon, Dec 26, 2016 at 12:48 PM, Thomas Kluyver  wrote:

> On 25 December 2016 at 03:30, René Dudfield  wrote:
>
>> I've been non contactable for a few weeks due to personal issues. Which I
>> guess was frustrating to Thomas, which has led to this latest effort to
>> make a new website.
>>
>
> I'm glad to see you back; I was a bit worried that something had happened
> to you. I hope things are OK.
>
> Truth be told, the website has been frustrating me for quite a long time,
> but your absence really highlighted the need for something that doesn't
> depend on a single person maintaining it, and I have seen on the mailing
> list that there's a lot of talent and enthusiasm that could be harnessed if
> the website was a more collaborative project.
>
>>
>>- most parts of the website can be updated (by wiki, bitbucket,
>>stackoverflow, etc)
>>
>> This is a good point, and I should update the 'Getting Started' page on
> the wiki. I cannot, however, see a way to update the all-important Download
> page.
>
>>
>>- we need to document who has access to which admin things (there are
>>a few people who have access to everything, but I guess not everyone knows
>>each other, and some people go inactive some times)
>>
>> +1. For instance, you mentioned that users jmm0 and TheSheep also have
> admin access to Disqus, but those usernames don't obviously relate to
> anyone I remember on the mailing list or on Bitbucket, so I'm not sure who
> they are or how to contact them.
>
>>
>>- moderation, respect and spam are issues we need to work on.
>>
>> +1. I hope you don't feel that our efforts to build a replacement site in
> your absence were disrespectful :-)
>
>> Looking forward to moving forward on the new website!
>>
> How would you like to see the transition happen? Now that you're back we
> can presumably make some updates to the current site, which reduces the
> pressure to replace it. I'd still like to see things like the download page
> generated from files in version control, so that people can update them
> through pull requests. My inclination is to move the wiki content into
> version control as well.
>
> For the game feed and the login system, how important do you think it is
> 

Re: [pygame] New pygame.org website

2016-12-26 Thread Thomas Kluyver
On 25 December 2016 at 03:30, René Dudfield  wrote:

> I've been non contactable for a few weeks due to personal issues. Which I
> guess was frustrating to Thomas, which has led to this latest effort to
> make a new website.
>

I'm glad to see you back; I was a bit worried that something had happened
to you. I hope things are OK.

Truth be told, the website has been frustrating me for quite a long time,
but your absence really highlighted the need for something that doesn't
depend on a single person maintaining it, and I have seen on the mailing
list that there's a lot of talent and enthusiasm that could be harnessed if
the website was a more collaborative project.

>
>- most parts of the website can be updated (by wiki, bitbucket,
>stackoverflow, etc)
>
> This is a good point, and I should update the 'Getting Started' page on
the wiki. I cannot, however, see a way to update the all-important Download
page.

>
>- we need to document who has access to which admin things (there are
>a few people who have access to everything, but I guess not everyone knows
>each other, and some people go inactive some times)
>
> +1. For instance, you mentioned that users jmm0 and TheSheep also have
admin access to Disqus, but those usernames don't obviously relate to
anyone I remember on the mailing list or on Bitbucket, so I'm not sure who
they are or how to contact them.

>
>- moderation, respect and spam are issues we need to work on.
>
> +1. I hope you don't feel that our efforts to build a replacement site in
your absence were disrespectful :-)

> Looking forward to moving forward on the new website!
>
How would you like to see the transition happen? Now that you're back we
can presumably make some updates to the current site, which reduces the
pressure to replace it. I'd still like to see things like the download page
generated from files in version control, so that people can update them
through pull requests. My inclination is to move the wiki content into
version control as well.

For the game feed and the login system, how important do you think it is to
maintain the data from the old site? We could try to build a Python web
application around the same database, and then switch over to it. That
would be significantly more work than making a new system from scratch, but
it means a smoother transition, and preserves the existing archive. Do you
want to keep using the current server for dynamic parts of a new site, or
move pygame away from it?

Thanks,
Thomas


Re: [pygame] New pygame.org website

2016-12-25 Thread Paul Vincent Craven
Could you add 'pvcraven' as well?

I messed around with Nikola. I can recreate their main documentation site,
but I'm not super-impressed with the tool. It looks like it would require
more work to set up our website an sync with GitHub pages rather than less
work than to just skip it and raw-code some html pages. I'd be willing to
work with it, but I don't think I'm willing to sink the time into setting
it up myself.

However, I like the design of their landing page:

https://getnikola.com/

I know it is bootstrappy, but it isn't hard to find the main things a
person would want to do.

Paul Vincent Craven

On Sat, Dec 24, 2016 at 4:00 AM, Thomas Kluyver  wrote:

> I have created an org called pygame-org, and invited everyone who has sent
> me their username (if I've missed someone, please let me know).
>
> https://github.com/pygame-org
>
> I'm not going to be looking at it much for a couple of weeks, but feel
> free to start working things out.
>
> On 24 December 2016 at 00:20, Radomir Dopieralski 
> wrote:
>
>> Note that I don't have a problem with the need to have a Github (or
>> Bitbucket) account to contribute to PyGame or its website themselves --
>> you have to use the tools that the project choose to contribute to that
>> project, and in a pinch you can always send your patches by e-mail. But
>> forcing all members of the PyGame community to become Github's
>> customers somehow feels different.
>>
>
> For all the reasons you list, I don't intend that the game feed be limited
> to games hosted on Github. I would like it to work much as it does on the
> current site: game developers supply a screenshot and a link, and can host
> their game (free or commercial) wherever they like.
>
> With the system as proposed, game developers will at first need a Github
> account to list their games on the feed. I don't think that's a problematic
> requirement, any more than needing a Bitbucket account to file a bug on
> Pygame. But we may be able to avoid even that requirement in the future
> with a submission interface that talks to Github on the user's behalf.
>
> Thanks,
> Thomas
>


Re: [pygame] New pygame.org website

2016-12-25 Thread Luke Paireepinart
Rene,
Thanks for the quick reply. Guess I don't understand why you would release
the source in bits and pieces? I'm excited to see where this website
rewrite goes, I've seen so many attempts in the past and none of them went
anywhere... Won't it be stymied by the unavailability of the source?

On Dec 24, 2016 9:31 PM, "René Dudfield"  wrote:

> Hi Luke,
>
> Yes I certainly do! It's of course necessary when I've been maintaining
> the website for the past decade. The plan continues to be to release parts
> of the source code as I go. So far there are some db migration scripts,
> which include tools to help scrub the db of private info. The screenshots
> can be exported easily as they are just a folder of files at the moment.
>
> I've been non contactable for a few weeks due to personal issues. Which I
> guess was frustrating to Thomas, which has led to this latest effort to
> make a new website.
>
>- most parts of the website can be updated (by wiki, bitbucket,
>stackoverflow, etc)
>- we need to document who has access to which admin things (there are
>a few people who have access to everything, but I guess not everyone knows
>each other, and some people go inactive some times)
>- moderation, respect and spam are issues we need to work on.
>
> Looking forward to moving forward on the new website!
>
>
> best,
>


Re: [pygame] New pygame.org website

2016-12-24 Thread René Dudfield
Hi Luke,

Yes I certainly do! It's of course necessary when I've been maintaining the
website for the past decade. The plan continues to be to release parts of
the source code as I go. So far there are some db migration scripts, which
include tools to help scrub the db of private info. The screenshots can be
exported easily as they are just a folder of files at the moment.

I've been non contactable for a few weeks due to personal issues. Which I
guess was frustrating to Thomas, which has led to this latest effort to
make a new website.

   - most parts of the website can be updated (by wiki, bitbucket,
   stackoverflow, etc)
   - we need to document who has access to which admin things (there are a
   few people who have access to everything, but I guess not everyone knows
   each other, and some people go inactive some times)
   - moderation, respect and spam are issues we need to work on.

Looking forward to moving forward on the new website!


best,


Re: [pygame] New pygame.org website

2016-12-24 Thread Luke Paireepinart
Rene,
Do you have access to all the content on the current website? Databases,
source code, etc?

On Dec 24, 2016 8:41 PM, "René Dudfield"  wrote:

Three people have access to disquss admin panel. jmm0, TheSheep and I.

I never noticed the adverts as I use an addblocker too. I never enabled
them, and at least once remember selecting them to not be enabled some
years ago. It looks like it was activated on September 19th this year
without the consent of anyone. I disabled it.


On Sun, Dec 18, 2016 at 8:12 PM, Thomas Kluyver  wrote:

> On 18 December 2016 at 19:07, Charles Cossé  wrote:
>
>> Rather than ditch disqus altogether, I would be willing to write to them
>> and ask if they wouldn't consider giving pygame a special version without
>> ads.  What do you all think about that?  Doesn't have to be me, either, but
>> just to complete the idea.
>
>
> I have a disqus account for my blog, and it looks like the ads can be
> disabled in the disqus control panel. They only serve them on sites with
> enough traffic in the first place, so I can't test.
>
> Does anyone have access to the Disqus account for Pygame so we can try to
> turn these off?
>
> The ads they're serving when I look are such trashy clickbait that I'm
> inclined to avoid the service entirely for new sites. If that's how they're
> going to make money, I want no part of it.
>


Re: [pygame] New pygame.org website

2016-12-24 Thread René Dudfield
Three people have access to disquss admin panel. jmm0, TheSheep and I.

I never noticed the adverts as I use an addblocker too. I never enabled
them, and at least once remember selecting them to not be enabled some
years ago. It looks like it was activated on September 19th this year
without the consent of anyone. I disabled it.


On Sun, Dec 18, 2016 at 8:12 PM, Thomas Kluyver  wrote:

> On 18 December 2016 at 19:07, Charles Cossé  wrote:
>
>> Rather than ditch disqus altogether, I would be willing to write to them
>> and ask if they wouldn't consider giving pygame a special version without
>> ads.  What do you all think about that?  Doesn't have to be me, either, but
>> just to complete the idea.
>
>
> I have a disqus account for my blog, and it looks like the ads can be
> disabled in the disqus control panel. They only serve them on sites with
> enough traffic in the first place, so I can't test.
>
> Does anyone have access to the Disqus account for Pygame so we can try to
> turn these off?
>
> The ads they're serving when I look are such trashy clickbait that I'm
> inclined to avoid the service entirely for new sites. If that's how they're
> going to make money, I want no part of it.
>


Re: [pygame] New pygame.org website

2016-12-24 Thread Martin Kühne
On Fri, Dec 23, 2016 at 10:46 PM, Radomir Dopieralski
 wrote:
> Please, no Angular, no leftpad.js, no client-side use-all-cpu
> works-only-in-my-favorite-browser unusable disabled-hostile confusing
> shiny technologies. That's exactly how the current website was created.
>
> There is already a perfectly good way of searching a static web page,
> without any processing on the server, built into your browser -- you can
> access it with ctrl+f.

I like your ideas. For cross-site search, maybe something simple
resembling python's site serach (which appears to work on my ofline
copy) could later be considered.

cheers!
mar77i


Re: [pygame] New pygame.org website

2016-12-24 Thread Thomas Kluyver
I have created an org called pygame-org, and invited everyone who has sent
me their username (if I've missed someone, please let me know).

https://github.com/pygame-org

I'm not going to be looking at it much for a couple of weeks, but feel free
to start working things out.

On 24 December 2016 at 00:20, Radomir Dopieralski 
wrote:

> Note that I don't have a problem with the need to have a Github (or
> Bitbucket) account to contribute to PyGame or its website themselves --
> you have to use the tools that the project choose to contribute to that
> project, and in a pinch you can always send your patches by e-mail. But
> forcing all members of the PyGame community to become Github's
> customers somehow feels different.
>

For all the reasons you list, I don't intend that the game feed be limited
to games hosted on Github. I would like it to work much as it does on the
current site: game developers supply a screenshot and a link, and can host
their game (free or commercial) wherever they like.

With the system as proposed, game developers will at first need a Github
account to list their games on the feed. I don't think that's a problematic
requirement, any more than needing a Bitbucket account to file a bug on
Pygame. But we may be able to avoid even that requirement in the future
with a submission interface that talks to Github on the user's behalf.

Thanks,
Thomas


Re: [pygame] New pygame.org website

2016-12-23 Thread DiliupG
i am glad to see that there are other people who feel that we should not
use github. Lateral thinking is good most times.
While we are at it I would like to suggest that we look at the Pygame
documentation and re write it for people who are learning from scratch.
There are a lot of places that it can elaborate a bit more with simple
examples.

On Sat, Dec 24, 2016 at 6:08 AM, Miriam English 
wrote:

> It's a pity you didn't read more than the first paragraph of my post,
> Daniel. I understand you getting impatient, and I know it looks like I'm
> trying to burst your bubble, but I'm not. I'm urging caution. I've seen too
> many projects come undone by charging forward without care.
>
> - Miriam
>
> Daniel Foerster wrote:
>
>> We are proposing to use github because it gives us both git source
>> control for versioning, free hosting, and a nice way to control
>> contribution to the repository. There aren't "additional complications" of
>> github, but rather desired features.
>>
>> — Daniel
>>
>> On 12/23/2016 04:44 PM, Miriam English wrote:
>>
>>> Hi Thomas,
>>>
>>> Those maintainers who have access to their part of the ibiblio site and
>>> to sourceforge projects can update them as often as they want. No matter
>>> what site you use it seems to me that there will still only be a small core
>>> of people with access, so the additional complications of github seem to me
>>> to be rather wasted.
>>>
>>> Do I understand it correctly? You are proposing to use github, something
>>> designed to easily branch updates to software, purely to host webpages? It
>>> seems a little like getting a lamborghini purely to do the weekly grocery
>>> shopping. Github is a new, cool thing, and might look like it is the
>>> solution to everything, but is it? (I notice there seems to be some
>>> confusion here -- some are saying everything should go on github, others
>>> seem to be insisting only the webpages.)
>>>
>>> Please note I'm not actually arguing against github. I know it sounds
>>> like I am, but I'm not. I'm cautioning that humans tend to get an idea
>>> fixed in their minds and we push for that regardless of its suitability. We
>>> get trapped in a mindset. I just want to ensure that doesn't screw the
>>> future pygame site by making the wrong choice early on when it could be
>>> changed.
>>>
>>> I'll throw in another idea: we could all put in a couple of dollars and
>>> buy a website which we could have *total* control over. That would give any
>>> degree of access or restriction desired, and the ability to host static
>>> pages until maybe we came up with a really easy way to do dynamic pages
>>> (personally, I prefer static pages). We could have any amount of anti-spam
>>> measure we wished. Again, I'm not actually pushing this idea; it is just
>>> another suggestion.
>>>
>>> And another: someone on this list is sure to be associated with a
>>> university. They often make available part of their site for worthy
>>> projects. That would allow a high degree of degree of access and autonomy,
>>> but would be free.
>>>
>>> I'm sure there are other possibilities.
>>>
>>> Cheers,
>>>
>>> - Miriam
>>>
>>>
>>> Thomas Kluyver wrote:
>>>
 Hi Miriam,

 Looking at ibiblio.org , it's talking about an
 application process to host a 'collection' there ("A decision will be made
 and you will be notified."). This sounds rather controlled for a simple
 static site, and I'm concerned that it won't be as easy as we want to
 update the site and for multiple people to work on it. Clicking around the
 distros section, it looks like most distros host downloads there but have a
 website somewhere else (so far, Fat Dog is the only one I've found with web
 pages there). This suggests to me that it's not ideal for hosting a 
 website.

 It's hard to put my finger on what's wrong with it, because clearly you
 *can* host static web pages there. But looking around the information pages
 and the Q site, I get a very strong feeling that hosting there would
 involve a lot of time and hassle that I don't want.

 Similarly for archive.org , I think it's intended
 as... well, an archive! That's valuable, but it's not the problem we're
 trying to solve.

 Github pages is a very convenient way to host a website, and to manage
 multiple people making changes to it. I know a lot of open source projects
 whose websites are hosted this way. It does require using git to update the
 site, and I'm sorry if that's difficult for you, but it's a system that
 works well for a lot of people. None of the arguments I've read so far
 provide a compelling reason /not/ to host a site on Github, and the only
 option that I see as a reasonable alternative is Gitlab, which presumably
 works in a very similar way to Github.

 > Is it possible to have something that is safe, but 

Re: [pygame] New pygame.org website

2016-12-23 Thread Miriam English
It's a pity you didn't read more than the first paragraph of my post, 
Daniel. I understand you getting impatient, and I know it looks like I'm 
trying to burst your bubble, but I'm not. I'm urging caution. I've seen 
too many projects come undone by charging forward without care.


- Miriam

Daniel Foerster wrote:
We are proposing to use github because it gives us both git source 
control for versioning, free hosting, and a nice way to control 
contribution to the repository. There aren't "additional 
complications" of github, but rather desired features.


— Daniel

On 12/23/2016 04:44 PM, Miriam English wrote:

Hi Thomas,

Those maintainers who have access to their part of the ibiblio site 
and to sourceforge projects can update them as often as they want. No 
matter what site you use it seems to me that there will still only be 
a small core of people with access, so the additional complications 
of github seem to me to be rather wasted.


Do I understand it correctly? You are proposing to use github, 
something designed to easily branch updates to software, purely to 
host webpages? It seems a little like getting a lamborghini purely to 
do the weekly grocery shopping. Github is a new, cool thing, and 
might look like it is the solution to everything, but is it? (I 
notice there seems to be some confusion here -- some are saying 
everything should go on github, others seem to be insisting only the 
webpages.)


Please note I'm not actually arguing against github. I know it sounds 
like I am, but I'm not. I'm cautioning that humans tend to get an 
idea fixed in their minds and we push for that regardless of its 
suitability. We get trapped in a mindset. I just want to ensure that 
doesn't screw the future pygame site by making the wrong choice early 
on when it could be changed.


I'll throw in another idea: we could all put in a couple of dollars 
and buy a website which we could have *total* control over. That 
would give any degree of access or restriction desired, and the 
ability to host static pages until maybe we came up with a really 
easy way to do dynamic pages (personally, I prefer static pages). We 
could have any amount of anti-spam measure we wished. Again, I'm not 
actually pushing this idea; it is just another suggestion.


And another: someone on this list is sure to be associated with a 
university. They often make available part of their site for worthy 
projects. That would allow a high degree of degree of access and 
autonomy, but would be free.


I'm sure there are other possibilities.

Cheers,

- Miriam


Thomas Kluyver wrote:

Hi Miriam,

Looking at ibiblio.org , it's talking about an 
application process to host a 'collection' there ("A decision will 
be made and you will be notified."). This sounds rather controlled 
for a simple static site, and I'm concerned that it won't be as easy 
as we want to update the site and for multiple people to work on it. 
Clicking around the distros section, it looks like most distros host 
downloads there but have a website somewhere else (so far, Fat Dog 
is the only one I've found with web pages there). This suggests to 
me that it's not ideal for hosting a website.


It's hard to put my finger on what's wrong with it, because clearly 
you *can* host static web pages there. But looking around the 
information pages and the Q site, I get a very strong feeling that 
hosting there would involve a lot of time and hassle that I don't want.


Similarly for archive.org , I think it's 
intended as... well, an archive! That's valuable, but it's not the 
problem we're trying to solve.


Github pages is a very convenient way to host a website, and to 
manage multiple people making changes to it. I know a lot of open 
source projects whose websites are hosted this way. It does require 
using git to update the site, and I'm sorry if that's difficult for 
you, but it's a system that works well for a lot of people. None of 
the arguments I've read so far provide a compelling reason /not/ to 
host a site on Github, and the only option that I see as a 
reasonable alternative is Gitlab, which presumably works in a very 
similar way to Github.


> Is it possible to have something that is safe, but easy for 
newbies to add games to a site?


I think it is, if we accept that it just needs to be 'safe enough'. 
Automatically adding 'nofollow' on user provided links reduces its 
value to spammers a lot. I believe Google's recaptcha tool does a 
reasonable job of stopping bots. And if it's still not enough, we 
can authenticate users and require an admin to approve a user's 
first submission.


Thomas

On 23 December 2016 at 01:45, Miriam English > wrote:


The two repositories I mentioned, ibiblio.org 
and archive.org  (I'm sure there are more)
have, as far as I know, no limits on storage.

Have a look, 

Re: [pygame] New pygame.org website

2016-12-23 Thread Radomir Dopieralski
On Fri, 23 Dec 2016 16:49:07 -0600
Luke Paireepinart  wrote:

>  The advantage I see of requiring users to host at github in a
> separate repo vs allowing arbitrary hosting is that you do not have
> to worry about spam links nearly as much. Just ask user for the repo
> name and that's it. The script that processes the requests can then
> verify that the provided name is a valid github repo and that it
> meets the standard guidelines and pull the readme in automatically as
> well as the link.  It could also show all releases on the pygame page
> just like the 'releases' tab, and we could promote content that is
> active whenever the static site generator runs (it could check each
> repo for activity).
> 
> When generating the site, if anything doesn't match the templates,
> throw it out automatically.
> 
> That also allows users to leverage github tools for reporting
> malicious content, and makes it much more likely that the content &
> links on the site will be accessible.  Allowing users to self host
> content is why, when you go back and look at some old forum posts
> from 5+ years ago online, none of the images load.here's an
> example, I checked about 10 random project IDs and found one where
> the content is no longer hosted on the site:
> http://pygame.org/project/1003/  If there is some interest I could
> definitely scan all the projects to determine how much dead links
> there are on the current site.

You are right about the benefits, of course, and some communities
embraced github as the only place to keep all their stuff (for instance,
the node.js community, with all those libraries in npm). However, there
is also a cost for that, and that is not just that any new users have
to learn to use git and github.

Github is a for-profit commercial company based in the USA. When you
create an account, your data is getting stored on their servers,
together with all the logs about your activity there. What's more, when
creating an account, you agree to their Terms of Service, and are
legally bound by them. Different people object to different parts of
that, but the important thing is that not everyone are comfortable with
this, and that we shouldn't be forcing people to do that just to get
their game on the website.

One especially problematic thing is that some of the better PyGame
games are actually commercial, closed-source games made for sale.
Github doesn't allow that, but we want to still show those games.

Note that I don't have a problem with the need to have a Github (or
Bitbucket) account to contribute to PyGame or its website themselves --
you have to use the tools that the project choose to contribute to that
project, and in a pinch you can always send your patches by e-mail. But
forcing all members of the PyGame community to become Github's
customers somehow feels different.

-- 
Radomir Dopieralski


Re: [pygame] New pygame.org website

2016-12-23 Thread Greg Ewing

Luke Paireepinart wrote:
Regarding Angular, it's a bit of a mischaraterization to say there's 
equivalence between an angular search of content and ctrl+f. For one, 
with angular only matching content could be shown, and different 
metadata could be used for searching (search on title, description, 
library, author, etc.)


Keep in mind that one can also use Google with a host name
to search for things on a specific site. That often works
better than whatever a site's custom search facility provides.

--
Greg



Re: [pygame] New pygame.org website

2016-12-23 Thread Daniel Foerster
We are proposing to use github because it gives us both git source 
control for versioning, free hosting, and a nice way to control 
contribution to the repository. There aren't "additional complications" 
of github, but rather desired features.


— Daniel

On 12/23/2016 04:44 PM, Miriam English wrote:

Hi Thomas,

Those maintainers who have access to their part of the ibiblio site 
and to sourceforge projects can update them as often as they want. No 
matter what site you use it seems to me that there will still only be 
a small core of people with access, so the additional complications of 
github seem to me to be rather wasted.


Do I understand it correctly? You are proposing to use github, 
something designed to easily branch updates to software, purely to 
host webpages? It seems a little like getting a lamborghini purely to 
do the weekly grocery shopping. Github is a new, cool thing, and might 
look like it is the solution to everything, but is it? (I notice there 
seems to be some confusion here -- some are saying everything should 
go on github, others seem to be insisting only the webpages.)


Please note I'm not actually arguing against github. I know it sounds 
like I am, but I'm not. I'm cautioning that humans tend to get an idea 
fixed in their minds and we push for that regardless of its 
suitability. We get trapped in a mindset. I just want to ensure that 
doesn't screw the future pygame site by making the wrong choice early 
on when it could be changed.


I'll throw in another idea: we could all put in a couple of dollars 
and buy a website which we could have *total* control over. That would 
give any degree of access or restriction desired, and the ability to 
host static pages until maybe we came up with a really easy way to do 
dynamic pages (personally, I prefer static pages). We could have any 
amount of anti-spam measure we wished. Again, I'm not actually pushing 
this idea; it is just another suggestion.


And another: someone on this list is sure to be associated with a 
university. They often make available part of their site for worthy 
projects. That would allow a high degree of degree of access and 
autonomy, but would be free.


I'm sure there are other possibilities.

Cheers,

- Miriam


Thomas Kluyver wrote:

Hi Miriam,

Looking at ibiblio.org , it's talking about an 
application process to host a 'collection' there ("A decision will be 
made and you will be notified."). This sounds rather controlled for a 
simple static site, and I'm concerned that it won't be as easy as we 
want to update the site and for multiple people to work on it. 
Clicking around the distros section, it looks like most distros host 
downloads there but have a website somewhere else (so far, Fat Dog is 
the only one I've found with web pages there). This suggests to me 
that it's not ideal for hosting a website.


It's hard to put my finger on what's wrong with it, because clearly 
you *can* host static web pages there. But looking around the 
information pages and the Q site, I get a very strong feeling that 
hosting there would involve a lot of time and hassle that I don't want.


Similarly for archive.org , I think it's intended 
as... well, an archive! That's valuable, but it's not the problem 
we're trying to solve.


Github pages is a very convenient way to host a website, and to 
manage multiple people making changes to it. I know a lot of open 
source projects whose websites are hosted this way. It does require 
using git to update the site, and I'm sorry if that's difficult for 
you, but it's a system that works well for a lot of people. None of 
the arguments I've read so far provide a compelling reason /not/ to 
host a site on Github, and the only option that I see as a reasonable 
alternative is Gitlab, which presumably works in a very similar way 
to Github.


> Is it possible to have something that is safe, but easy for newbies 
to add games to a site?


I think it is, if we accept that it just needs to be 'safe enough'. 
Automatically adding 'nofollow' on user provided links reduces its 
value to spammers a lot. I believe Google's recaptcha tool does a 
reasonable job of stopping bots. And if it's still not enough, we can 
authenticate users and require an admin to approve a user's first 
submission.


Thomas

On 23 December 2016 at 01:45, Miriam English > wrote:


The two repositories I mentioned, ibiblio.org 
and archive.org  (I'm sure there are more)
have, as far as I know, no limits on storage.

Have a look, for instance at the amount stored for Puppy Linux at
ibiblio:
http://distro.ibiblio.org/puppylinux/


Each of those subdirectories you see relates to a different kind
of Puppy.

The packages directories contain programs specifically tailored
for a 

Re: [pygame] New pygame.org website

2016-12-23 Thread Thomas Kluyver
On 23 Dec 2016 10:49 p.m., "Luke Paireepinart" 
wrote

 The advantage I see of requiring users to host at github in a separate
repo vs allowing arbitrary hosting is that you do not have to worry about
spam links nearly as much. Just ask user for the repo name and that's it.
The script that processes the requests can then verify that the provided
name is a valid github repo and that it meets the standard guidelines and
pull the readme in automatically as well as the link.


I'm not particularly keen on requiring that the games be hosted on github,
but if they add it to our listing with a github pull request, I don't think
we'll have an issue with spam.

So has anyone started on any of this? is there some community controlled
github that we could start with?  I'd be interested in contributing some
effort to this.


Not yet, but I think I'll create a github org in the morning (Europe time).
Writing from my phone now, about to sleep. Thanks for volunteering!

Anyone who's interested in contributing to this site, send me an email with
your github username so I can add you to the org when I create it. :-)


Re: [pygame] New pygame.org website

2016-12-23 Thread Luke Paireepinart
I agree with you that we don't want to host the games inside the main
repo.  There was mention earlier in the thread of including the games in
there. That was what I was referring to.  For example

> What are the data limits for media files in GitHub? Is there any concern
that by merging in all of the games into a single repo that you'll end up
having to pay monthly for storage? If so, who would pick up that bill? What
happens if it isn't paid, do we lose access to the games?

 The advantage I see of requiring users to host at github in a separate
repo vs allowing arbitrary hosting is that you do not have to worry about
spam links nearly as much. Just ask user for the repo name and that's it.
The script that processes the requests can then verify that the provided
name is a valid github repo and that it meets the standard guidelines and
pull the readme in automatically as well as the link.  It could also show
all releases on the pygame page just like the 'releases' tab, and we could
promote content that is active whenever the static site generator runs (it
could check each repo for activity).

When generating the site, if anything doesn't match the templates, throw it
out automatically.

That also allows users to leverage github tools for reporting malicious
content, and makes it much more likely that the content & links on the site
will be accessible.  Allowing users to self host content is why, when you
go back and look at some old forum posts from 5+ years ago online, none of
the images load.here's an example, I checked about 10 random project
IDs and found one where the content is no longer hosted on the site:
http://pygame.org/project/1003/  If there is some interest I could
definitely scan all the projects to determine how much dead links there are
on the current site.

Regarding Angular, it's a bit of a mischaraterization to say there's
equivalence between an angular search of content and ctrl+f. For one, with
angular only matching content could be shown, and different metadata could
be used for searching (search on title, description, library, author, etc.)
Ctrl+f would require the entire game list to be loaded with all content.
However, I will admit I hadn't seen the new hifi site until just now and
after seeing it I completely understand your concerns about things getting
out of control. Fair enough. I think a static, clean site is a great
starting point. Github pages is great too.

So has anyone started on any of this? is there some community controlled
github that we could start with?  I'd be interested in contributing some
effort to this.  Wouldn't mind learning some python static site tools.
Mostly do C# these days but still have the love of Python from when I first
started developing software.



On Dec 23, 2016 3:47 PM, "Radomir Dopieralski"  wrote:

On Fri, 23 Dec 2016 14:01:57 -0600
Luke Paireepinart  wrote:

> Can't we just make it so only a few known-good users have access to
> merge to master and then use pull requests for edits to the site from
> the community?  this is a common way to do it both for sites and
> otherwise - Ionic does their tutorial websites this way.

This is not the problem, and yes, it has been done this way so far, and
it will continue to be done that way, most likely.

> The only real issue I would see is that you wouldn't really want a
> single repo with binaries or even of source of all games submitted.
> That would clutter up the repo for the website with essentially
> backend data edits.

We don't want to host those games. As people have here already noted
multiple times, there is no shortage of places where you can host the
files and source code for your games. All we need is a link, a
description, and perhaps a screenshot. That's it.

> I would suggest making a template repository for users to fork on
> GitHub that would include an editable readme.md with a good starting
> framework. They could update the readme to include descriptions of
> their games and these could be pulled into a list.

It's not necessary for their projects to follow any particular
structure or template. We could, however, have a template for adding an
entry for your game (title, author, link, description, screenshot,
etc.) to the list, and then have that included in the static generation
of the website.

> Regarding static vs dynamic sites and games lists, we could
> preprocess the games list into one big json file and then just
> implement the game list view as an Angular application.  That would
> allow sorting/filtering/searching of content with no dynamic
> processing on the server side whatsoever - just when a new project is
> accepted, that json file would be updated to include the link and
> some tags about each game.

Please, no Angular, no leftpad.js, no client-side use-all-cpu
works-only-in-my-favorite-browser unusable disabled-hostile confusing
shiny technologies. That's exactly how the current website was created.

There is 

Re: [pygame] New pygame.org website

2016-12-23 Thread Thomas Kluyver
On 23 Dec 2016 9:47 p.m., "Radomir Dopieralski"  wrote:

Let's first build the simplest possible thing, and we can refine it and
add bling if we have spare resources for that.


+1. I'm not against making a fancy front-end if people are willing to
maintain it, but I'm a big fan of building something simple at first, and
then adding features later.

As a side note, what are we going to do with the existing game list?
Are we going to import/migrate it to the new website?


I'm not sure. I think we'd transfer at least a few of the recent ones to
seed the new list. We can go further back if someone wants to scrape it. I
see it more as a way to showcase new games and tools rather than an
archive, but other people may disagree.

I hope that the old site will remain accessible after the DNS changes at
something like old.Pygame.org, for as long as that server stays up.


Re: [pygame] New pygame.org website

2016-12-23 Thread Miriam English

Hi Thomas,

Those maintainers who have access to their part of the ibiblio site and 
to sourceforge projects can update them as often as they want. No matter 
what site you use it seems to me that there will still only be a small 
core of people with access, so the additional complications of github 
seem to me to be rather wasted.


Do I understand it correctly? You are proposing to use github, something 
designed to easily branch updates to software, purely to host webpages? 
It seems a little like getting a lamborghini purely to do the weekly 
grocery shopping. Github is a new, cool thing, and might look like it is 
the solution to everything, but is it? (I notice there seems to be some 
confusion here -- some are saying everything should go on github, others 
seem to be insisting only the webpages.)


Please note I'm not actually arguing against github. I know it sounds 
like I am, but I'm not. I'm cautioning that humans tend to get an idea 
fixed in their minds and we push for that regardless of its suitability. 
We get trapped in a mindset. I just want to ensure that doesn't screw 
the future pygame site by making the wrong choice early on when it could 
be changed.


I'll throw in another idea: we could all put in a couple of dollars and 
buy a website which we could have *total* control over. That would give 
any degree of access or restriction desired, and the ability to host 
static pages until maybe we came up with a really easy way to do dynamic 
pages (personally, I prefer static pages). We could have any amount of 
anti-spam measure we wished. Again, I'm not actually pushing this idea; 
it is just another suggestion.


And another: someone on this list is sure to be associated with a 
university. They often make available part of their site for worthy 
projects. That would allow a high degree of degree of access and 
autonomy, but would be free.


I'm sure there are other possibilities.

Cheers,

- Miriam


Thomas Kluyver wrote:

Hi Miriam,

Looking at ibiblio.org , it's talking about an 
application process to host a 'collection' there ("A decision will be 
made and you will be notified."). This sounds rather controlled for a 
simple static site, and I'm concerned that it won't be as easy as we 
want to update the site and for multiple people to work on it. 
Clicking around the distros section, it looks like most distros host 
downloads there but have a website somewhere else (so far, Fat Dog is 
the only one I've found with web pages there). This suggests to me 
that it's not ideal for hosting a website.


It's hard to put my finger on what's wrong with it, because clearly 
you *can* host static web pages there. But looking around the 
information pages and the Q site, I get a very strong feeling that 
hosting there would involve a lot of time and hassle that I don't want.


Similarly for archive.org , I think it's intended 
as... well, an archive! That's valuable, but it's not the problem 
we're trying to solve.


Github pages is a very convenient way to host a website, and to manage 
multiple people making changes to it. I know a lot of open source 
projects whose websites are hosted this way. It does require using git 
to update the site, and I'm sorry if that's difficult for you, but 
it's a system that works well for a lot of people. None of the 
arguments I've read so far provide a compelling reason /not/ to host a 
site on Github, and the only option that I see as a reasonable 
alternative is Gitlab, which presumably works in a very similar way to 
Github.


> Is it possible to have something that is safe, but easy for newbies 
to add games to a site?


I think it is, if we accept that it just needs to be 'safe enough'. 
Automatically adding 'nofollow' on user provided links reduces its 
value to spammers a lot. I believe Google's recaptcha tool does a 
reasonable job of stopping bots. And if it's still not enough, we can 
authenticate users and require an admin to approve a user's first 
submission.


Thomas

On 23 December 2016 at 01:45, Miriam English > wrote:


The two repositories I mentioned, ibiblio.org 
and archive.org  (I'm sure there are more)
have, as far as I know, no limits on storage.

Have a look, for instance at the amount stored for Puppy Linux at
ibiblio:
http://distro.ibiblio.org/puppylinux/


Each of those subdirectories you see relates to a different kind
of Puppy.

The packages directories contain programs specifically tailored
for a particular distribution of Puppy. The pet_packages-lucid
directory alone contains more than 10 Gigabytes of programs, and
there are more than 30 Puppy distros with associated package
collections.

The puppy-528 directory contains a couple of ISO CD images for
Puppy Lucid 528. It also 

Re: [pygame] New pygame.org website

2016-12-23 Thread Radomir Dopieralski
On Fri, 23 Dec 2016 14:01:57 -0600
Luke Paireepinart  wrote:

> Can't we just make it so only a few known-good users have access to
> merge to master and then use pull requests for edits to the site from
> the community?  this is a common way to do it both for sites and
> otherwise - Ionic does their tutorial websites this way.

This is not the problem, and yes, it has been done this way so far, and
it will continue to be done that way, most likely.

> The only real issue I would see is that you wouldn't really want a
> single repo with binaries or even of source of all games submitted.
> That would clutter up the repo for the website with essentially
> backend data edits.

We don't want to host those games. As people have here already noted
multiple times, there is no shortage of places where you can host the
files and source code for your games. All we need is a link, a
description, and perhaps a screenshot. That's it.

> I would suggest making a template repository for users to fork on
> GitHub that would include an editable readme.md with a good starting
> framework. They could update the readme to include descriptions of
> their games and these could be pulled into a list.

It's not necessary for their projects to follow any particular
structure or template. We could, however, have a template for adding an
entry for your game (title, author, link, description, screenshot,
etc.) to the list, and then have that included in the static generation
of the website.

> Regarding static vs dynamic sites and games lists, we could
> preprocess the games list into one big json file and then just
> implement the game list view as an Angular application.  That would
> allow sorting/filtering/searching of content with no dynamic
> processing on the server side whatsoever - just when a new project is
> accepted, that json file would be updated to include the link and
> some tags about each game.

Please, no Angular, no leftpad.js, no client-side use-all-cpu
works-only-in-my-favorite-browser unusable disabled-hostile confusing
shiny technologies. That's exactly how the current website was created.

There is already a perfectly good way of searching a static web page,
without any processing on the server, built into your browser -- you can
access it with ctrl+f.

Let's first build the simplest possible thing, and we can refine it and
add bling if we have spare resources for that.


As a side note, what are we going to do with the existing game list?
Are we going to import/migrate it to the new website?

-- 
Radomir Dopieralski


Re: [pygame] New pygame.org website

2016-12-23 Thread Luke Paireepinart
Can't we just make it so only a few known-good users have access to merge
to master and then use pull requests for edits to the site from the
community?  this is a common way to do it both for sites and otherwise -
Ionic does their tutorial websites this way.

The only real issue I would see is that you wouldn't really want a single
repo with binaries or even of source of all games submitted.  That would
clutter up the repo for the website with essentially backend data edits.

I would suggest making a template repository for users to fork on GitHub
that would include an editable readme.md with a good starting framework.
They could update the readme to include descriptions of their games and
these could be pulled into a list.

Regarding static vs dynamic sites and games lists, we could preprocess the
games list into one big json file and then just implement the game list
view as an Angular application.  That would allow
sorting/filtering/searching of content with no dynamic processing on the
server side whatsoever - just when a new project is accepted, that json
file would be updated to include the link and some tags about each game.

On Fri, Dec 23, 2016 at 12:49 PM, Thomas Kluyver  wrote:

> Hi Miriam,
>
> Looking at ibiblio.org, it's talking about an application process to host
> a 'collection' there ("A decision will be made and you will be notified.").
> This sounds rather controlled for a simple static site, and I'm concerned
> that it won't be as easy as we want to update the site and for multiple
> people to work on it. Clicking around the distros section, it looks like
> most distros host downloads there but have a website somewhere else (so
> far, Fat Dog is the only one I've found with web pages there). This
> suggests to me that it's not ideal for hosting a website.
>
> It's hard to put my finger on what's wrong with it, because clearly you
> *can* host static web pages there. But looking around the information pages
> and the Q site, I get a very strong feeling that hosting there would
> involve a lot of time and hassle that I don't want.
>
> Similarly for archive.org, I think it's intended as... well, an archive!
> That's valuable, but it's not the problem we're trying to solve.
>
> Github pages is a very convenient way to host a website, and to manage
> multiple people making changes to it. I know a lot of open source projects
> whose websites are hosted this way. It does require using git to update the
> site, and I'm sorry if that's difficult for you, but it's a system that
> works well for a lot of people. None of the arguments I've read so far
> provide a compelling reason *not* to host a site on Github, and the only
> option that I see as a reasonable alternative is Gitlab, which presumably
> works in a very similar way to Github.
>
> > Is it possible to have something that is safe, but easy for newbies to
> add games to a site?
>
> I think it is, if we accept that it just needs to be 'safe enough'.
> Automatically adding 'nofollow' on user provided links reduces its value to
> spammers a lot. I believe Google's recaptcha tool does a reasonable job of
> stopping bots. And if it's still not enough, we can authenticate users and
> require an admin to approve a user's first submission.
>
> Thomas
>
> On 23 December 2016 at 01:45, Miriam English 
> wrote:
>
>> The two repositories I mentioned, ibiblio.org and archive.org (I'm sure
>> there are more) have, as far as I know, no limits on storage.
>>
>> Have a look, for instance at the amount stored for Puppy Linux at ibiblio:
>> http://distro.ibiblio.org/puppylinux/
>>
>> Each of those subdirectories you see relates to a different kind of Puppy.
>>
>> The packages directories contain programs specifically tailored for a
>> particular distribution of Puppy. The pet_packages-lucid directory alone
>> contains more than 10 Gigabytes of programs, and there are more than 30
>> Puppy distros with associated package collections.
>>
>> The puppy-528 directory contains a couple of ISO CD images for Puppy
>> Lucid 528. It also contains an explanatory webpage:
>> http://distro.ibiblio.org/puppylinux/puppy-5.2.8/release-Lucid-528.htm
>>
>> Most of the main distro directories contain such a page.
>>
>> There is lots more on ibiblio, as a quick wander around
>> http://distro.ibiblio.org/ will show.
>> They also have multiple mirrors around the world, so if one set of
>> servers has a problem others are available.
>>
>> Cheers,
>>
>> - Miriam
>>
>>
>> Charles Cossé wrote:
>>
>>> Hi,
>>>
>>> On Thu, Dec 22, 2016 at 2:02 PM, Miriam English >> > wrote:
>>>
>>> I don't see the point of using github for the web pages and
>>> keeping the content elsewhere. I don't have a lot of experience
>>> using github (I find it a pain actually). Github is intended as a
>>> versioning system. That has no utility for a pygame repository, as
>>> far as I 

Re: [pygame] New pygame.org website

2016-12-23 Thread Thomas Kluyver
Hi Miriam,

Looking at ibiblio.org, it's talking about an application process to host a
'collection' there ("A decision will be made and you will be notified.").
This sounds rather controlled for a simple static site, and I'm concerned
that it won't be as easy as we want to update the site and for multiple
people to work on it. Clicking around the distros section, it looks like
most distros host downloads there but have a website somewhere else (so
far, Fat Dog is the only one I've found with web pages there). This
suggests to me that it's not ideal for hosting a website.

It's hard to put my finger on what's wrong with it, because clearly you
*can* host static web pages there. But looking around the information pages
and the Q site, I get a very strong feeling that hosting there would
involve a lot of time and hassle that I don't want.

Similarly for archive.org, I think it's intended as... well, an archive!
That's valuable, but it's not the problem we're trying to solve.

Github pages is a very convenient way to host a website, and to manage
multiple people making changes to it. I know a lot of open source projects
whose websites are hosted this way. It does require using git to update the
site, and I'm sorry if that's difficult for you, but it's a system that
works well for a lot of people. None of the arguments I've read so far
provide a compelling reason *not* to host a site on Github, and the only
option that I see as a reasonable alternative is Gitlab, which presumably
works in a very similar way to Github.

> Is it possible to have something that is safe, but easy for newbies to
add games to a site?

I think it is, if we accept that it just needs to be 'safe enough'.
Automatically adding 'nofollow' on user provided links reduces its value to
spammers a lot. I believe Google's recaptcha tool does a reasonable job of
stopping bots. And if it's still not enough, we can authenticate users and
require an admin to approve a user's first submission.

Thomas

On 23 December 2016 at 01:45, Miriam English  wrote:

> The two repositories I mentioned, ibiblio.org and archive.org (I'm sure
> there are more) have, as far as I know, no limits on storage.
>
> Have a look, for instance at the amount stored for Puppy Linux at ibiblio:
> http://distro.ibiblio.org/puppylinux/
>
> Each of those subdirectories you see relates to a different kind of Puppy.
>
> The packages directories contain programs specifically tailored for a
> particular distribution of Puppy. The pet_packages-lucid directory alone
> contains more than 10 Gigabytes of programs, and there are more than 30
> Puppy distros with associated package collections.
>
> The puppy-528 directory contains a couple of ISO CD images for Puppy Lucid
> 528. It also contains an explanatory webpage:
> http://distro.ibiblio.org/puppylinux/puppy-5.2.8/release-Lucid-528.htm
>
> Most of the main distro directories contain such a page.
>
> There is lots more on ibiblio, as a quick wander around
> http://distro.ibiblio.org/ will show.
> They also have multiple mirrors around the world, so if one set of servers
> has a problem others are available.
>
> Cheers,
>
> - Miriam
>
>
> Charles Cossé wrote:
>
>> Hi,
>>
>> On Thu, Dec 22, 2016 at 2:02 PM, Miriam English > > wrote:
>>
>> I don't see the point of using github for the web pages and
>> keeping the content elsewhere. I don't have a lot of experience
>> using github (I find it a pain actually). Github is intended as a
>> versioning system. That has no utility for a pygame repository, as
>> far as I can see -- or at least no advantage over an ordinary
>> repository built purely with that purpose in mind.
>>
>> Wouldn't it be simpler to keep the whole thing in a repository? I
>> mentioned 2 earlier: archive.org  and
>> ibiblio.org , both of which are free and very
>>
>> secure.
>>
>>
>> I can say a little bit that might help until someone with more knowledge
>> has time to reply ... With GitHub pages your website is "just another"
>> repo.  That's the main thing I wanted to point out.  There are no storage
>> limits, and I'm pretty sure that GitHub would be happy to help pygame
>> accomodation-wise if pygame needed anything special (within reason).   I
>> also know that there is a 4 gigabyte file limit on GitHub.  (I know this
>> because I once wanted to host an 8G SD card image and had to get it down to
>> 4G in order to be housed on GitHub).
>>
>> FWIW, I have also managed to run webapps on GitHub via GitHub pages.  For
>> example http://asymptopia.github.io/TuxMathScrabble-2015/.
>>
>> And, not trying to direct traffic to my site or anything, but here's my
>> own site using GitHub pages: https://asymptopia.github.io/
>>
>> Best regards,
>> Charles
>>
>> Cheers,
>>
>> - Miriam
>>
>>
>> Thomas Kluyver wrote:
>>
>> Thanks everyone for 

Re: [pygame] New pygame.org website

2016-12-22 Thread Miriam English
Claudio, I expect it wouldn't be difficult to point the pygame.org 
domain to the content on ibiblio or archive.org, or sourceforge, or 
whatever. Dynamic content might be difficult though.


claudio canepa wrote:
@Miriam: all the examples you gave points to the hosting domain ( 
ibiblio.org  ); we want pygame.org 
 or similar with a hosting that allows DNS 
redirection from pygame.org  to the content. That 
way, if at some future time we want to migrate or add a non-static 
part all that is needed is to change the DNS entries.


Probably size is not a problem : pygame site provides docs, articles 
and game announcements; it does not host the game downloads.




On Thu, Dec 22, 2016 at 10:45 PM, Miriam English 
> wrote:


The two repositories I mentioned, ibiblio.org 
and archive.org  (I'm sure there are more)
have, as far as I know, no limits on storage.

Have a look, for instance at the amount stored for Puppy Linux at
ibiblio:
http://distro.ibiblio.org/puppylinux/


Each of those subdirectories you see relates to a different kind
of Puppy.

The packages directories contain programs specifically tailored
for a particular distribution of Puppy. The pet_packages-lucid
directory alone contains more than 10 Gigabytes of programs, and
there are more than 30 Puppy distros with associated package
collections.

The puppy-528 directory contains a couple of ISO CD images for
Puppy Lucid 528. It also contains an explanatory webpage:
http://distro.ibiblio.org/puppylinux/puppy-5.2.8/release-Lucid-528.htm


Most of the main distro directories contain such a page.

There is lots more on ibiblio, as a quick wander around
http://distro.ibiblio.org/ will show.
They also have multiple mirrors around the world, so if one set of
servers has a problem others are available.

Cheers,

- Miriam


Charles Cossé wrote:

Hi,

On Thu, Dec 22, 2016 at 2:02 PM, Miriam English

>> wrote:

I don't see the point of using github for the web pages and
keeping the content elsewhere. I don't have a lot of
experience
using github (I find it a pain actually). Github is
intended as a
versioning system. That has no utility for a pygame
repository, as
far as I can see -- or at least no advantage over an ordinary
repository built purely with that purpose in mind.

Wouldn't it be simpler to keep the whole thing in a
repository? I
mentioned 2 earlier: archive.org 
 and
ibiblio.org  , both of
which are free and very

secure.


I can say a little bit that might help until someone with more
knowledge has time to reply ... With GitHub pages your website
is "just another" repo.  That's the main thing I wanted to
point out.  There are no storage limits, and I'm pretty sure
that GitHub would be happy to help pygame accomodation-wise if
pygame needed anything special (within reason).   I also know
that there is a 4 gigabyte file limit on GitHub.  (I know this
because I once wanted to host an 8G SD card image and had to
get it down to 4G in order to be housed on GitHub).

FWIW, I have also managed to run webapps on GitHub via GitHub
pages.  For example
http://asymptopia.github.io/TuxMathScrabble-2015/
.

And, not trying to direct traffic to my site or anything, but
here's my own site using GitHub pages:
https://asymptopia.github.io/

Best regards,
Charles

Cheers,

- Miriam


Thomas Kluyver wrote:

Thanks everyone for your input. In the interests of making
progress, I'd like to propose:

- The informational site will be hosted on Github
pages; I've
used this for a number of websites before, it's
reliable, we
can point an external domain to it, and I imagine that
most of
the likely contributors have Github accounts already.
- The pages will be generated by a Python static site
generator. There doesn't seem to be a strong feeling
between
Sphinx/Nikola/Pelican, so it will likely depend on who
 

Re: [pygame] New pygame.org website

2016-12-22 Thread claudio canepa
@Miriam: all the examples you gave points to the hosting domain (
ibiblio.org ); we want pygame.org or similar with a hosting that allows DNS
redirection from pygame.org to the content. That way, if at some future
time we want to migrate or add a non-static part all that is needed is to
change the DNS entries.

Probably size is not a problem : pygame site provides docs, articles and
game announcements; it does not host the game downloads.



On Thu, Dec 22, 2016 at 10:45 PM, Miriam English 
wrote:

> The two repositories I mentioned, ibiblio.org and archive.org (I'm sure
> there are more) have, as far as I know, no limits on storage.
>
> Have a look, for instance at the amount stored for Puppy Linux at ibiblio:
> http://distro.ibiblio.org/puppylinux/
>
> Each of those subdirectories you see relates to a different kind of Puppy.
>
> The packages directories contain programs specifically tailored for a
> particular distribution of Puppy. The pet_packages-lucid directory alone
> contains more than 10 Gigabytes of programs, and there are more than 30
> Puppy distros with associated package collections.
>
> The puppy-528 directory contains a couple of ISO CD images for Puppy Lucid
> 528. It also contains an explanatory webpage:
> http://distro.ibiblio.org/puppylinux/puppy-5.2.8/release-Lucid-528.htm
>
> Most of the main distro directories contain such a page.
>
> There is lots more on ibiblio, as a quick wander around
> http://distro.ibiblio.org/ will show.
> They also have multiple mirrors around the world, so if one set of servers
> has a problem others are available.
>
> Cheers,
>
> - Miriam
>
>
> Charles Cossé wrote:
>
>> Hi,
>>
>> On Thu, Dec 22, 2016 at 2:02 PM, Miriam English > > wrote:
>>
>> I don't see the point of using github for the web pages and
>> keeping the content elsewhere. I don't have a lot of experience
>> using github (I find it a pain actually). Github is intended as a
>> versioning system. That has no utility for a pygame repository, as
>> far as I can see -- or at least no advantage over an ordinary
>> repository built purely with that purpose in mind.
>>
>> Wouldn't it be simpler to keep the whole thing in a repository? I
>> mentioned 2 earlier: archive.org  and
>> ibiblio.org , both of which are free and very
>>
>> secure.
>>
>>
>> I can say a little bit that might help until someone with more knowledge
>> has time to reply ... With GitHub pages your website is "just another"
>> repo.  That's the main thing I wanted to point out.  There are no storage
>> limits, and I'm pretty sure that GitHub would be happy to help pygame
>> accomodation-wise if pygame needed anything special (within reason).   I
>> also know that there is a 4 gigabyte file limit on GitHub.  (I know this
>> because I once wanted to host an 8G SD card image and had to get it down to
>> 4G in order to be housed on GitHub).
>>
>> FWIW, I have also managed to run webapps on GitHub via GitHub pages.  For
>> example http://asymptopia.github.io/TuxMathScrabble-2015/.
>>
>> And, not trying to direct traffic to my site or anything, but here's my
>> own site using GitHub pages: https://asymptopia.github.io/
>>
>> Best regards,
>> Charles
>>
>> Cheers,
>>
>> - Miriam
>>
>>
>> Thomas Kluyver wrote:
>>
>> Thanks everyone for your input. In the interests of making
>> progress, I'd like to propose:
>>
>> - The informational site will be hosted on Github pages; I've
>> used this for a number of websites before, it's reliable, we
>> can point an external domain to it, and I imagine that most of
>> the likely contributors have Github accounts already.
>> - The pages will be generated by a Python static site
>> generator. There doesn't seem to be a strong feeling between
>> Sphinx/Nikola/Pelican, so it will likely depend on who is most
>> excited to start building it.
>> - The game feed will also be generated from content in Github,
>> so /at first/ developers will need to submit a PR to add a
>> game. Once that's working, we can build a simpler submission
>> interface on Heroku/Appengine/similar which can push content
>> to Github. Ideally the data will be in a format which would
>> could move elsewhere later if necessary.
>>
>> I like the concept of drawing the game feed from an external
>> source, but I don't think any of the sources proposed match
>> what we want closely enough.
>>
>> Does anybody object to any of those proposals?
>>
>> Thanks,
>> Thomas
>>
>> On 18 December 2016 at 20:18, Miriam English
>> 
>> >
>> >> wrote:

Re: [pygame] New pygame.org website

2016-12-22 Thread Miriam English
Daniel, fair enough. A user-friendly submission system that can be 
fairly well automated without opening itself to the blasted spammers 
would be a very good thing. The two I mentioned (archive.org and 
ibiblio.org) are not that. They are secure, but restricted in who can 
upload. Game developers would have to send their products to a core 
group (perhaps via this list). Everybody could check out the product and 
the core group member(s) could upload it.


Is it possible to have something that is safe, but easy for newbies to 
add games to a site? I'm tempted to say it's impossible, but in the past 
when I've said that about anything it's come back to bite me. :)


Cheers,

- Miriam


Daniel Foerster wrote:

Miriam,

I think you're missing the issue here. Almost all of the content would 
be put in GitHub (Thomas even suggests that everything go there). 
Using ibiblio.org/archive.org  doesn't 
help us any as far as the game showcase goes, which is the main matter 
of debate; you're still trying to find a good user-friendly way to 
submit content without opening the door wide open for abuse.


On Thu, Dec 22, 2016 at 3:02 PM, Miriam English 
> wrote:


I don't see the point of using github for the web pages and
keeping the content elsewhere. I don't have a lot of experience
using github (I find it a pain actually). Github is intended as a
versioning system. That has no utility for a pygame repository, as
far as I can see -- or at least no advantage over an ordinary
repository built purely with that purpose in mind.

Wouldn't it be simpler to keep the whole thing in a repository? I
mentioned 2 earlier: archive.org  and
ibiblio.org , both of which are free and very
secure.

Cheers,

- Miriam


Thomas Kluyver wrote:

Thanks everyone for your input. In the interests of making
progress, I'd like to propose:

- The informational site will be hosted on Github pages; I've
used this for a number of websites before, it's reliable, we
can point an external domain to it, and I imagine that most of
the likely contributors have Github accounts already.
- The pages will be generated by a Python static site
generator. There doesn't seem to be a strong feeling between
Sphinx/Nikola/Pelican, so it will likely depend on who is most
excited to start building it.
- The game feed will also be generated from content in Github,
so /at first/ developers will need to submit a PR to add a
game. Once that's working, we can build a simpler submission
interface on Heroku/Appengine/similar which can push content
to Github. Ideally the data will be in a format which would
could move elsewhere later if necessary.

I like the concept of drawing the game feed from an external
source, but I don't think any of the sources proposed match
what we want closely enough.

Does anybody object to any of those proposals?

Thanks,
Thomas

On 18 December 2016 at 20:18, Miriam English

>> wrote:

http://ibiblio.org is an enormous, free repository that also lets
you have static webpages. Many of the Linux distros are hosted
from there as well as much else too. I don't know how
you'd set up
a comments system there. It may be possible.

http://archive.org is another gigantic free repository. They
already have a comments system built into their pages. I don't
know how it works. It might be worth checking out.

Both these organisations are free and are aimed at helping
make
content available to the community which might otherwise
be lost.
You have complete control over the look of webpages at
ibiblio.org 
 because you simply upload static pages.

I don't know how much control over the look archive.org

 provides because everything is dynamically

served from xml data, I think. It might be possible to add
static
content, I don't know.

But both are free, permanently available, and have
excellent security.

Cheers,

- Miriam



Peter Shinners wrote:

Gitlab also has great static site support for free,
and you
can use custom domains. They also make it easy to run most
static generation tools as a CI job. Although part of me
thinks just 

Re: [pygame] New pygame.org website

2016-12-22 Thread Miriam English
The two repositories I mentioned, ibiblio.org and archive.org (I'm sure 
there are more) have, as far as I know, no limits on storage.


Have a look, for instance at the amount stored for Puppy Linux at ibiblio:
http://distro.ibiblio.org/puppylinux/

Each of those subdirectories you see relates to a different kind of Puppy.

The packages directories contain programs specifically tailored for a 
particular distribution of Puppy. The pet_packages-lucid directory alone 
contains more than 10 Gigabytes of programs, and there are more than 30 
Puppy distros with associated package collections.


The puppy-528 directory contains a couple of ISO CD images for Puppy 
Lucid 528. It also contains an explanatory webpage:

http://distro.ibiblio.org/puppylinux/puppy-5.2.8/release-Lucid-528.htm

Most of the main distro directories contain such a page.

There is lots more on ibiblio, as a quick wander around 
http://distro.ibiblio.org/ will show.
They also have multiple mirrors around the world, so if one set of 
servers has a problem others are available.


Cheers,

- Miriam


Charles Cossé wrote:

Hi,

On Thu, Dec 22, 2016 at 2:02 PM, Miriam English 
> wrote:


I don't see the point of using github for the web pages and
keeping the content elsewhere. I don't have a lot of experience
using github (I find it a pain actually). Github is intended as a
versioning system. That has no utility for a pygame repository, as
far as I can see -- or at least no advantage over an ordinary
repository built purely with that purpose in mind.

Wouldn't it be simpler to keep the whole thing in a repository? I
mentioned 2 earlier: archive.org  and
ibiblio.org , both of which are free and very
secure.


I can say a little bit that might help until someone with more 
knowledge has time to reply ... With GitHub pages your website is 
"just another" repo.  That's the main thing I wanted to point out.  
There are no storage limits, and I'm pretty sure that GitHub would be 
happy to help pygame accomodation-wise if pygame needed anything 
special (within reason).   I also know that there is a 4 gigabyte file 
limit on GitHub.  (I know this because I once wanted to host an 8G SD 
card image and had to get it down to 4G in order to be housed on GitHub).


FWIW, I have also managed to run webapps on GitHub via GitHub pages.  
For example http://asymptopia.github.io/TuxMathScrabble-2015/.


And, not trying to direct traffic to my site or anything, but here's 
my own site using GitHub pages: https://asymptopia.github.io/


Best regards,
Charles

Cheers,

- Miriam


Thomas Kluyver wrote:

Thanks everyone for your input. In the interests of making
progress, I'd like to propose:

- The informational site will be hosted on Github pages; I've
used this for a number of websites before, it's reliable, we
can point an external domain to it, and I imagine that most of
the likely contributors have Github accounts already.
- The pages will be generated by a Python static site
generator. There doesn't seem to be a strong feeling between
Sphinx/Nikola/Pelican, so it will likely depend on who is most
excited to start building it.
- The game feed will also be generated from content in Github,
so /at first/ developers will need to submit a PR to add a
game. Once that's working, we can build a simpler submission
interface on Heroku/Appengine/similar which can push content
to Github. Ideally the data will be in a format which would
could move elsewhere later if necessary.

I like the concept of drawing the game feed from an external
source, but I don't think any of the sources proposed match
what we want closely enough.

Does anybody object to any of those proposals?

Thanks,
Thomas

On 18 December 2016 at 20:18, Miriam English

>> wrote:

http://ibiblio.org is an enormous, free repository that also lets
you have static webpages. Many of the Linux distros are hosted
from there as well as much else too. I don't know how
you'd set up
a comments system there. It may be possible.

http://archive.org is another gigantic free repository. They
already have a comments system built into their pages. I don't
know how it works. It might be worth checking out.

Both these organisations are free and are aimed at helping
make
content available to the community which might otherwise
be lost.
You have complete control over the look of webpages at
ibiblio.org 

Re: [pygame] New pygame.org website

2016-12-22 Thread Daniel Foerster
Miriam,

I think you're missing the issue here. Almost all of the content would be
put in GitHub (Thomas even suggests that everything go there). Using
ibiblio.org/archive.org doesn't help us any as far as the game showcase
goes, which is the main matter of debate; you're still trying to find a
good user-friendly way to submit content without opening the door wide open
for abuse.

On Thu, Dec 22, 2016 at 3:02 PM, Miriam English 
wrote:

> I don't see the point of using github for the web pages and keeping the
> content elsewhere. I don't have a lot of experience using github (I find it
> a pain actually). Github is intended as a versioning system. That has no
> utility for a pygame repository, as far as I can see -- or at least no
> advantage over an ordinary repository built purely with that purpose in
> mind.
>
> Wouldn't it be simpler to keep the whole thing in a repository? I
> mentioned 2 earlier: archive.org and ibiblio.org, both of which are free
> and very secure.
>
> Cheers,
>
> - Miriam
>
>
> Thomas Kluyver wrote:
>
>> Thanks everyone for your input. In the interests of making progress, I'd
>> like to propose:
>>
>> - The informational site will be hosted on Github pages; I've used this
>> for a number of websites before, it's reliable, we can point an external
>> domain to it, and I imagine that most of the likely contributors have
>> Github accounts already.
>> - The pages will be generated by a Python static site generator. There
>> doesn't seem to be a strong feeling between Sphinx/Nikola/Pelican, so it
>> will likely depend on who is most excited to start building it.
>> - The game feed will also be generated from content in Github, so /at
>> first/ developers will need to submit a PR to add a game. Once that's
>> working, we can build a simpler submission interface on
>> Heroku/Appengine/similar which can push content to Github. Ideally the data
>> will be in a format which would could move elsewhere later if necessary.
>>
>> I like the concept of drawing the game feed from an external source, but
>> I don't think any of the sources proposed match what we want closely enough.
>>
>> Does anybody object to any of those proposals?
>>
>> Thanks,
>> Thomas
>>
>> On 18 December 2016 at 20:18, Miriam English > > wrote:
>>
>> http://ibiblio.org is an enormous, free repository that also lets
>> you have static webpages. Many of the Linux distros are hosted
>> from there as well as much else too. I don't know how you'd set up
>> a comments system there. It may be possible.
>>
>> http://archive.org is another gigantic free repository. They
>> already have a comments system built into their pages. I don't
>> know how it works. It might be worth checking out.
>>
>> Both these organisations are free and are aimed at helping make
>> content available to the community which might otherwise be lost.
>> You have complete control over the look of webpages at ibiblio.org
>>  because you simply upload static pages.
>>
>> I don't know how much control over the look archive.org
>>  provides because everything is dynamically
>>
>> served from xml data, I think. It might be possible to add static
>> content, I don't know.
>>
>> But both are free, permanently available, and have excellent security.
>>
>> Cheers,
>>
>> - Miriam
>>
>>
>>
>> Peter Shinners wrote:
>>
>> Gitlab also has great static site support for free, and you
>> can use custom domains. They also make it easy to run most
>> static generation tools as a CI job. Although part of me
>> thinks just pushing the static content is easiest. It sounds
>> to me like there's a list of acceptable hosting choices that
>> won't cost anything.
>>
>> Keeping the games list as a feed from other service sounds
>> like it has the best chance of working.
>>
>>
>> On 12/17/2016 10:51 PM, Lenard Lindstrom wrote:
>>
>> Bitbucket also has static web site support. I set one up
>> for the Pygame docs awhile ago, but have not maintained it:
>>
>> http://pygame.bitbucket.org/docs/pygame/
>> 
>>
>> The repository is here:
>>
>> https://bitbucket.org/pygame/pygame.bitbucket.org
>> 
>>
>> Lenard Lindstrom
>>
>> On 16-12-17 09:16 PM, Daniel Foerster wrote:
>>
>> You know, I suppose we could just use GitHub pages.
>>
>> On Dec 17, 2016 17:32, "Charles Cossé"
>> 
>> >>
>> wrote:
>>
>>
>>
>> On Sat, Dec 17, 2016 at 4:12 PM, 

Re: [pygame] New pygame.org website

2016-12-22 Thread Charles Cossé
Hi,

On Thu, Dec 22, 2016 at 2:02 PM, Miriam English 
wrote:

> I don't see the point of using github for the web pages and keeping the
> content elsewhere. I don't have a lot of experience using github (I find it
> a pain actually). Github is intended as a versioning system. That has no
> utility for a pygame repository, as far as I can see -- or at least no
> advantage over an ordinary repository built purely with that purpose in
> mind.
>
> Wouldn't it be simpler to keep the whole thing in a repository? I
> mentioned 2 earlier: archive.org and ibiblio.org, both of which are free
> and very secure.
>
>
I can say a little bit that might help until someone with more knowledge
has time to reply ... With GitHub pages your website is "just another"
repo.  That's the main thing I wanted to point out.  There are no storage
limits, and I'm pretty sure that GitHub would be happy to help pygame
accomodation-wise if pygame needed anything special (within reason).   I
also know that there is a 4 gigabyte file limit on GitHub.  (I know this
because I once wanted to host an 8G SD card image and had to get it down to
4G in order to be housed on GitHub).

FWIW, I have also managed to run webapps on GitHub via GitHub pages.  For
example http://asymptopia.github.io/TuxMathScrabble-2015/.

And, not trying to direct traffic to my site or anything, but here's my own
site using GitHub pages: https://asymptopia.github.io/

Best regards,
Charles



> Cheers,
>
> - Miriam
>
>
> Thomas Kluyver wrote:
>
>> Thanks everyone for your input. In the interests of making progress, I'd
>> like to propose:
>>
>> - The informational site will be hosted on Github pages; I've used this
>> for a number of websites before, it's reliable, we can point an external
>> domain to it, and I imagine that most of the likely contributors have
>> Github accounts already.
>> - The pages will be generated by a Python static site generator. There
>> doesn't seem to be a strong feeling between Sphinx/Nikola/Pelican, so it
>> will likely depend on who is most excited to start building it.
>> - The game feed will also be generated from content in Github, so /at
>> first/ developers will need to submit a PR to add a game. Once that's
>> working, we can build a simpler submission interface on
>> Heroku/Appengine/similar which can push content to Github. Ideally the data
>> will be in a format which would could move elsewhere later if necessary.
>>
>> I like the concept of drawing the game feed from an external source, but
>> I don't think any of the sources proposed match what we want closely enough.
>>
>> Does anybody object to any of those proposals?
>>
>> Thanks,
>> Thomas
>>
>> On 18 December 2016 at 20:18, Miriam English > > wrote:
>>
>> http://ibiblio.org is an enormous, free repository that also lets
>> you have static webpages. Many of the Linux distros are hosted
>> from there as well as much else too. I don't know how you'd set up
>> a comments system there. It may be possible.
>>
>> http://archive.org is another gigantic free repository. They
>> already have a comments system built into their pages. I don't
>> know how it works. It might be worth checking out.
>>
>> Both these organisations are free and are aimed at helping make
>> content available to the community which might otherwise be lost.
>> You have complete control over the look of webpages at ibiblio.org
>>  because you simply upload static pages.
>>
>> I don't know how much control over the look archive.org
>>  provides because everything is dynamically
>>
>> served from xml data, I think. It might be possible to add static
>> content, I don't know.
>>
>> But both are free, permanently available, and have excellent security.
>>
>> Cheers,
>>
>> - Miriam
>>
>>
>>
>> Peter Shinners wrote:
>>
>> Gitlab also has great static site support for free, and you
>> can use custom domains. They also make it easy to run most
>> static generation tools as a CI job. Although part of me
>> thinks just pushing the static content is easiest. It sounds
>> to me like there's a list of acceptable hosting choices that
>> won't cost anything.
>>
>> Keeping the games list as a feed from other service sounds
>> like it has the best chance of working.
>>
>>
>> On 12/17/2016 10:51 PM, Lenard Lindstrom wrote:
>>
>> Bitbucket also has static web site support. I set one up
>> for the Pygame docs awhile ago, but have not maintained it:
>>
>> http://pygame.bitbucket.org/docs/pygame/
>> 
>>
>> The repository is here:
>>
>> https://bitbucket.org/pygame/pygame.bitbucket.org
>> 

Re: [pygame] New pygame.org website

2016-12-22 Thread Miriam English
I don't see the point of using github for the web pages and keeping the 
content elsewhere. I don't have a lot of experience using github (I find 
it a pain actually). Github is intended as a versioning system. That has 
no utility for a pygame repository, as far as I can see -- or at least 
no advantage over an ordinary repository built purely with that purpose 
in mind.


Wouldn't it be simpler to keep the whole thing in a repository? I 
mentioned 2 earlier: archive.org and ibiblio.org, both of which are free 
and very secure.


Cheers,

- Miriam


Thomas Kluyver wrote:
Thanks everyone for your input. In the interests of making progress, 
I'd like to propose:


- The informational site will be hosted on Github pages; I've used 
this for a number of websites before, it's reliable, we can point an 
external domain to it, and I imagine that most of the likely 
contributors have Github accounts already.
- The pages will be generated by a Python static site generator. There 
doesn't seem to be a strong feeling between Sphinx/Nikola/Pelican, so 
it will likely depend on who is most excited to start building it.
- The game feed will also be generated from content in Github, so /at 
first/ developers will need to submit a PR to add a game. Once that's 
working, we can build a simpler submission interface on 
Heroku/Appengine/similar which can push content to Github. Ideally the 
data will be in a format which would could move elsewhere later if 
necessary.


I like the concept of drawing the game feed from an external source, 
but I don't think any of the sources proposed match what we want 
closely enough.


Does anybody object to any of those proposals?

Thanks,
Thomas

On 18 December 2016 at 20:18, Miriam English > wrote:


http://ibiblio.org is an enormous, free repository that also lets
you have static webpages. Many of the Linux distros are hosted
from there as well as much else too. I don't know how you'd set up
a comments system there. It may be possible.

http://archive.org is another gigantic free repository. They
already have a comments system built into their pages. I don't
know how it works. It might be worth checking out.

Both these organisations are free and are aimed at helping make
content available to the community which might otherwise be lost.
You have complete control over the look of webpages at ibiblio.org
 because you simply upload static pages.

I don't know how much control over the look archive.org
 provides because everything is dynamically
served from xml data, I think. It might be possible to add static
content, I don't know.

But both are free, permanently available, and have excellent security.

Cheers,

- Miriam



Peter Shinners wrote:

Gitlab also has great static site support for free, and you
can use custom domains. They also make it easy to run most
static generation tools as a CI job. Although part of me
thinks just pushing the static content is easiest. It sounds
to me like there's a list of acceptable hosting choices that
won't cost anything.

Keeping the games list as a feed from other service sounds
like it has the best chance of working.


On 12/17/2016 10:51 PM, Lenard Lindstrom wrote:

Bitbucket also has static web site support. I set one up
for the Pygame docs awhile ago, but have not maintained it:

http://pygame.bitbucket.org/docs/pygame/


The repository is here:

https://bitbucket.org/pygame/pygame.bitbucket.org


Lenard Lindstrom

On 16-12-17 09:16 PM, Daniel Foerster wrote:

You know, I suppose we could just use GitHub pages.

On Dec 17, 2016 17:32, "Charles Cossé"

>>
wrote:



On Sat, Dec 17, 2016 at 4:12 PM, Daniel Foerster

>> wrote:

Using S3/CloudFront is a lot cheaper than the
EC2 setup you're
imagining (and which a Django stack would
require).



I never said to use Amazon at all.  Just use the
current server,
whatever it is (unless it's Amazon).

On 12/17/2016 05:11 PM, Charles Cossé wrote:

Yikes!  who's gonna pay the Amazon bill?

On Sat, Dec 17, 

Re: [pygame] New pygame.org website

2016-12-22 Thread William Manire
What are the data limits for media files in GitHub? Is there any concern
that by merging in all of the games into a single repo that you'll end up
having to pay monthly for storage? If so, who would pick up that bill? What
happens if it isn't paid, do we lose access to the games?

On Thu, Dec 22, 2016, 7:26 AM Thomas Kluyver  wrote:

> Thanks everyone for your input. In the interests of making progress, I'd
> like to propose:
>
> - The informational site will be hosted on Github pages; I've used this
> for a number of websites before, it's reliable, we can point an external
> domain to it, and I imagine that most of the likely contributors have
> Github accounts already.
> - The pages will be generated by a Python static site generator. There
> doesn't seem to be a strong feeling between Sphinx/Nikola/Pelican, so it
> will likely depend on who is most excited to start building it.
> - The game feed will also be generated from content in Github, so *at
> first* developers will need to submit a PR to add a game. Once that's
> working, we can build a simpler submission interface on
> Heroku/Appengine/similar which can push content to Github. Ideally the data
> will be in a format which would could move elsewhere later if necessary.
>
> I like the concept of drawing the game feed from an external source, but I
> don't think any of the sources proposed match what we want closely enough.
>
> Does anybody object to any of those proposals?
>
> Thanks,
> Thomas
>
> On 18 December 2016 at 20:18, Miriam English 
> wrote:
>
> http://ibiblio.org is an enormous, free repository that also lets you
> have static webpages. Many of the Linux distros are hosted from there as
> well as much else too. I don't know how you'd set up a comments system
> there. It may be possible.
>
> http://archive.org is another gigantic free repository. They already have
> a comments system built into their pages. I don't know how it works. It
> might be worth checking out.
>
> Both these organisations are free and are aimed at helping make content
> available to the community which might otherwise be lost. You have complete
> control over the look of webpages at ibiblio.org because you simply
> upload static pages.
>
> I don't know how much control over the look archive.org provides because
> everything is dynamically served from xml data, I think. It might be
> possible to add static content, I don't know.
>
> But both are free, permanently available, and have excellent security.
>
> Cheers,
>
> - Miriam
>
>
>
> Peter Shinners wrote:
>
> Gitlab also has great static site support for free, and you can use custom
> domains. They also make it easy to run most static generation tools as a CI
> job. Although part of me thinks just pushing the static content is easiest.
> It sounds to me like there's a list of acceptable hosting choices that
> won't cost anything.
>
> Keeping the games list as a feed from other service sounds like it has the
> best chance of working.
>
>
> On 12/17/2016 10:51 PM, Lenard Lindstrom wrote:
>
> Bitbucket also has static web site support. I set one up for the Pygame
> docs awhile ago, but have not maintained it:
>
> http://pygame.bitbucket.org/docs/pygame/
>
> The repository is here:
>
> https://bitbucket.org/pygame/pygame.bitbucket.org
>
> Lenard Lindstrom
>
> On 16-12-17 09:16 PM, Daniel Foerster wrote:
>
> You know, I suppose we could just use GitHub pages.
>
> On Dec 17, 2016 17:32, "Charles Cossé" > wrote:
>
>
>
> On Sat, Dec 17, 2016 at 4:12 PM, Daniel Foerster
> > wrote:
>
> Using S3/CloudFront is a lot cheaper than the EC2 setup you're
> imagining (and which a Django stack would require).
>
>
>
> I never said to use Amazon at all.  Just use the current server,
> whatever it is (unless it's Amazon).
>
> On 12/17/2016 05:11 PM, Charles Cossé wrote:
>
> Yikes!  who's gonna pay the Amazon bill?
>
> On Sat, Dec 17, 2016 at 4:09 PM, Paul Vincent Craven
> > wrote:
>
> If most of the site is static, then I think Django would
> be overkill. The static portion of the site can easily be
> deployed via Amazon S3/CloudFront and then we'd not have
> to maintain a server.
>
> Paul Vincent Craven
>
> On Sat, Dec 17, 2016 at 5:00 PM, Charles Cossé
> > wrote:
>
>
> On Sat, Dec 17, 2016 at 3:26 PM, Thomas Kluyver
> > wrote:
>
>
> So far, I think the proposals for the static
> information part of the site are Nikola (a static
> site generator oriented around blogs) and Sphinx
> (oriented around docs). Both are written in
> 

Re: [pygame] New pygame.org website

2016-12-22 Thread Thomas Kluyver
On 22 December 2016 at 16:13, Charles Cossé  wrote:

> I suspect that there are many people, me included, who are familiar with
> parts of the plan you have described, but not all.  For example, knowing
> how to setup GitHub pages, but never having done the daily feed part, or
> not completely clear about static "generation".   So this could become a
> learning experience for a lot of people, if only just as observers.  What
> do you think about taking the extra trouble to make the effort somewhat of
> a class on how to do all these things?


I'm definitely on board with it being a learning experience for people,
though I'd like those people to be more participants than observers! I do
not have the time to build this site myself, so I'm relying on the good
people of this mailing list to make it happen, and trying to limit myself
to coordinating things to make it possible. So if you know anything at all
about HTML or Github pages, and you're willing to learn, you're definitely
welcome.

To expand on what I mean by 'static site generators': a static website is a
set of HTML files, which don't need to run any code on the server. But
editing HTML by hand when you want to change something is a pain. So a
static site generator is a tool which combines HTML templates with content
in a simpler markup language like markdown or restructuredtext, to generate
the HTML pages. A maintainer builds the site and uploads the new pages,
whereas a dynamic web application like Wordpress generates the HTML on the
server. There are loads of different SSGs (it's quite easy to make a simple
one), but Nikola & Pelican are two popular Python ones.


Re: [pygame] New pygame.org website

2016-12-22 Thread Charles Cossé
Hi Thomas,
I suspect that there are many people, me included, who are familiar with
parts of the plan you have described, but not all.  For example, knowing
how to setup GitHub pages, but never having done the daily feed part, or
not completely clear about static "generation".   So this could become a
learning experience for a lot of people, if only just as observers.  What
do you think about taking the extra trouble to make the effort somewhat of
a class on how to do all these things?
-Charles

On Thu, Dec 22, 2016 at 8:25 AM, Thomas Kluyver  wrote:

> Thanks everyone for your input. In the interests of making progress, I'd
> like to propose:
>
> - The informational site will be hosted on Github pages; I've used this
> for a number of websites before, it's reliable, we can point an external
> domain to it, and I imagine that most of the likely contributors have
> Github accounts already.
> - The pages will be generated by a Python static site generator. There
> doesn't seem to be a strong feeling between Sphinx/Nikola/Pelican, so it
> will likely depend on who is most excited to start building it.
> - The game feed will also be generated from content in Github, so *at
> first* developers will need to submit a PR to add a game. Once that's
> working, we can build a simpler submission interface on
> Heroku/Appengine/similar which can push content to Github. Ideally the data
> will be in a format which would could move elsewhere later if necessary.
>
> I like the concept of drawing the game feed from an external source, but I
> don't think any of the sources proposed match what we want closely enough.
>
> Does anybody object to any of those proposals?
>
> Thanks,
> Thomas
>
> On 18 December 2016 at 20:18, Miriam English 
> wrote:
>
>> http://ibiblio.org is an enormous, free repository that also lets you
>> have static webpages. Many of the Linux distros are hosted from there as
>> well as much else too. I don't know how you'd set up a comments system
>> there. It may be possible.
>>
>> http://archive.org is another gigantic free repository. They already
>> have a comments system built into their pages. I don't know how it works.
>> It might be worth checking out.
>>
>> Both these organisations are free and are aimed at helping make content
>> available to the community which might otherwise be lost. You have complete
>> control over the look of webpages at ibiblio.org because you simply
>> upload static pages.
>>
>> I don't know how much control over the look archive.org provides because
>> everything is dynamically served from xml data, I think. It might be
>> possible to add static content, I don't know.
>>
>> But both are free, permanently available, and have excellent security.
>>
>> Cheers,
>>
>> - Miriam
>>
>>
>>
>> Peter Shinners wrote:
>>
>>> Gitlab also has great static site support for free, and you can use
>>> custom domains. They also make it easy to run most static generation tools
>>> as a CI job. Although part of me thinks just pushing the static content is
>>> easiest. It sounds to me like there's a list of acceptable hosting choices
>>> that won't cost anything.
>>>
>>> Keeping the games list as a feed from other service sounds like it has
>>> the best chance of working.
>>>
>>>
>>> On 12/17/2016 10:51 PM, Lenard Lindstrom wrote:
>>>
 Bitbucket also has static web site support. I set one up for the Pygame
 docs awhile ago, but have not maintained it:

 http://pygame.bitbucket.org/docs/pygame/

 The repository is here:

 https://bitbucket.org/pygame/pygame.bitbucket.org

 Lenard Lindstrom

 On 16-12-17 09:16 PM, Daniel Foerster wrote:

> You know, I suppose we could just use GitHub pages.
>
> On Dec 17, 2016 17:32, "Charles Cossé" > wrote:
>
>
>
> On Sat, Dec 17, 2016 at 4:12 PM, Daniel Foerster
> > wrote:
>
> Using S3/CloudFront is a lot cheaper than the EC2 setup you're
> imagining (and which a Django stack would require).
>
>
>
> I never said to use Amazon at all.  Just use the current server,
> whatever it is (unless it's Amazon).
>
> On 12/17/2016 05:11 PM, Charles Cossé wrote:
>
>> Yikes!  who's gonna pay the Amazon bill?
>>
>> On Sat, Dec 17, 2016 at 4:09 PM, Paul Vincent Craven
>> > wrote:
>>
>> If most of the site is static, then I think Django would
>> be overkill. The static portion of the site can easily be
>> deployed via Amazon S3/CloudFront and then we'd not have
>> to maintain a server.
>>
>> Paul Vincent Craven
>>
>> On Sat, Dec 17, 2016 at 5:00 PM, Charles Cossé
>> 

Re: [pygame] New pygame.org website

2016-12-22 Thread Thomas Kluyver
Thanks everyone for your input. In the interests of making progress, I'd
like to propose:

- The informational site will be hosted on Github pages; I've used this for
a number of websites before, it's reliable, we can point an external domain
to it, and I imagine that most of the likely contributors have Github
accounts already.
- The pages will be generated by a Python static site generator. There
doesn't seem to be a strong feeling between Sphinx/Nikola/Pelican, so it
will likely depend on who is most excited to start building it.
- The game feed will also be generated from content in Github, so *at first*
developers will need to submit a PR to add a game. Once that's working, we
can build a simpler submission interface on Heroku/Appengine/similar which
can push content to Github. Ideally the data will be in a format which
would could move elsewhere later if necessary.

I like the concept of drawing the game feed from an external source, but I
don't think any of the sources proposed match what we want closely enough.

Does anybody object to any of those proposals?

Thanks,
Thomas

On 18 December 2016 at 20:18, Miriam English  wrote:

> http://ibiblio.org is an enormous, free repository that also lets you
> have static webpages. Many of the Linux distros are hosted from there as
> well as much else too. I don't know how you'd set up a comments system
> there. It may be possible.
>
> http://archive.org is another gigantic free repository. They already have
> a comments system built into their pages. I don't know how it works. It
> might be worth checking out.
>
> Both these organisations are free and are aimed at helping make content
> available to the community which might otherwise be lost. You have complete
> control over the look of webpages at ibiblio.org because you simply
> upload static pages.
>
> I don't know how much control over the look archive.org provides because
> everything is dynamically served from xml data, I think. It might be
> possible to add static content, I don't know.
>
> But both are free, permanently available, and have excellent security.
>
> Cheers,
>
> - Miriam
>
>
>
> Peter Shinners wrote:
>
>> Gitlab also has great static site support for free, and you can use
>> custom domains. They also make it easy to run most static generation tools
>> as a CI job. Although part of me thinks just pushing the static content is
>> easiest. It sounds to me like there's a list of acceptable hosting choices
>> that won't cost anything.
>>
>> Keeping the games list as a feed from other service sounds like it has
>> the best chance of working.
>>
>>
>> On 12/17/2016 10:51 PM, Lenard Lindstrom wrote:
>>
>>> Bitbucket also has static web site support. I set one up for the Pygame
>>> docs awhile ago, but have not maintained it:
>>>
>>> http://pygame.bitbucket.org/docs/pygame/
>>>
>>> The repository is here:
>>>
>>> https://bitbucket.org/pygame/pygame.bitbucket.org
>>>
>>> Lenard Lindstrom
>>>
>>> On 16-12-17 09:16 PM, Daniel Foerster wrote:
>>>
 You know, I suppose we could just use GitHub pages.

 On Dec 17, 2016 17:32, "Charles Cossé" >> cco...@gmail.com>> wrote:



 On Sat, Dec 17, 2016 at 4:12 PM, Daniel Foerster
 > wrote:

 Using S3/CloudFront is a lot cheaper than the EC2 setup you're
 imagining (and which a Django stack would require).



 I never said to use Amazon at all.  Just use the current server,
 whatever it is (unless it's Amazon).

 On 12/17/2016 05:11 PM, Charles Cossé wrote:

> Yikes!  who's gonna pay the Amazon bill?
>
> On Sat, Dec 17, 2016 at 4:09 PM, Paul Vincent Craven
> > wrote:
>
> If most of the site is static, then I think Django would
> be overkill. The static portion of the site can easily be
> deployed via Amazon S3/CloudFront and then we'd not have
> to maintain a server.
>
> Paul Vincent Craven
>
> On Sat, Dec 17, 2016 at 5:00 PM, Charles Cossé
> > wrote:
>
>
> On Sat, Dec 17, 2016 at 3:26 PM, Thomas Kluyver
> > wrote:
>
>
> So far, I think the proposals for the static
> information part of the site are Nikola (a static
> site generator oriented around blogs) and Sphinx
> (oriented around docs). Both are written in
> Python. Does anyone want to make the case for any
> other system?
>
>
> Can Django factor-in there? I guess it would reside
> underneathe 

Re: [pygame] New pygame.org website

2016-12-18 Thread Miriam English
http://ibiblio.org is an enormous, free repository that also lets you 
have static webpages. Many of the Linux distros are hosted from there as 
well as much else too. I don't know how you'd set up a comments system 
there. It may be possible.


http://archive.org is another gigantic free repository. They already 
have a comments system built into their pages. I don't know how it 
works. It might be worth checking out.


Both these organisations are free and are aimed at helping make content 
available to the community which might otherwise be lost. You have 
complete control over the look of webpages at ibiblio.org because you 
simply upload static pages.


I don't know how much control over the look archive.org provides because 
everything is dynamically served from xml data, I think. It might be 
possible to add static content, I don't know.


But both are free, permanently available, and have excellent security.

Cheers,

- Miriam


Peter Shinners wrote:
Gitlab also has great static site support for free, and you can use 
custom domains. They also make it easy to run most static generation 
tools as a CI job. Although part of me thinks just pushing the static 
content is easiest. It sounds to me like there's a list of acceptable 
hosting choices that won't cost anything.


Keeping the games list as a feed from other service sounds like it has 
the best chance of working.



On 12/17/2016 10:51 PM, Lenard Lindstrom wrote:
Bitbucket also has static web site support. I set one up for the 
Pygame docs awhile ago, but have not maintained it:


http://pygame.bitbucket.org/docs/pygame/

The repository is here:

https://bitbucket.org/pygame/pygame.bitbucket.org

Lenard Lindstrom

On 16-12-17 09:16 PM, Daniel Foerster wrote:

You know, I suppose we could just use GitHub pages.

On Dec 17, 2016 17:32, "Charles Cossé" > wrote:




On Sat, Dec 17, 2016 at 4:12 PM, Daniel Foerster
> wrote:

Using S3/CloudFront is a lot cheaper than the EC2 setup you're
imagining (and which a Django stack would require).



I never said to use Amazon at all.  Just use the current server,
whatever it is (unless it's Amazon).

On 12/17/2016 05:11 PM, Charles Cossé wrote:

Yikes!  who's gonna pay the Amazon bill?

On Sat, Dec 17, 2016 at 4:09 PM, Paul Vincent Craven
> wrote:

If most of the site is static, then I think Django would
be overkill. The static portion of the site can easily be
deployed via Amazon S3/CloudFront and then we'd not have
to maintain a server.

Paul Vincent Craven

On Sat, Dec 17, 2016 at 5:00 PM, Charles Cossé
> wrote:


On Sat, Dec 17, 2016 at 3:26 PM, Thomas Kluyver
> wrote:


So far, I think the proposals for the static
information part of the site are Nikola (a static
site generator oriented around blogs) and Sphinx
(oriented around docs). Both are written in
Python. Does anyone want to make the case for any
other system?


Can Django factor-in there? I guess it would reside
underneathe the other pkgs ... but might as well run
Python through-and-through imho.





--
Linkedin  |
E-Learning 







--
Linkedin  | E-Learning












--
There are two wolves and they're always fighting.
One is darkness and despair. The other is light and hope.
Which wolf wins?
Whichever one you feed.
 -- Casey in Brad Bird's movie "Tomorrowland"



Re: [pygame] New pygame.org website

2016-12-18 Thread Thomas Kluyver
On 18 December 2016 at 19:07, Charles Cossé  wrote:

> Rather than ditch disqus altogether, I would be willing to write to them
> and ask if they wouldn't consider giving pygame a special version without
> ads.  What do you all think about that?  Doesn't have to be me, either, but
> just to complete the idea.


I have a disqus account for my blog, and it looks like the ads can be
disabled in the disqus control panel. They only serve them on sites with
enough traffic in the first place, so I can't test.

Does anyone have access to the Disqus account for Pygame so we can try to
turn these off?

The ads they're serving when I look are such trashy clickbait that I'm
inclined to avoid the service entirely for new sites. If that's how they're
going to make money, I want no part of it.


Re: [pygame] New pygame.org website

2016-12-18 Thread Lenard Lindstrom

The ad appears to be added by Disqus, which powers the comments.

On 16-12-18 02:36 AM, Thomas Kluyver wrote:
Yuck. I always use an adblocker, so I hadn't seen the 'sponsored 
links' until now. I agree that they're hideous, and we definitely 
shouldn't have them on the new site. I wonder if they were put on 
there deliberately, or if the site has been compromised.


On 18 December 2016 at 09:42, Charles Cossé > wrote:


Would it be possible to eliminate those unsightly "sponsored
links" advertisements going forward?
I just logged-in for first time in 2 years and there's Donald
Trump and Angelina Jolie on my project page
 ...
yikes!





Re: [pygame] New pygame.org website

2016-12-18 Thread Peter Shinners
Gitlab also has great static site support for free, and you can use 
custom domains. They also make it easy to run most static generation 
tools as a CI job. Although part of me thinks just pushing the static 
content is easiest. It sounds to me like there's a list of acceptable 
hosting choices that won't cost anything.


Keeping the games list as a feed from other service sounds like it has 
the best chance of working.



On 12/17/2016 10:51 PM, Lenard Lindstrom wrote:
Bitbucket also has static web site support. I set one up for the 
Pygame docs awhile ago, but have not maintained it:


http://pygame.bitbucket.org/docs/pygame/

The repository is here:

https://bitbucket.org/pygame/pygame.bitbucket.org

Lenard Lindstrom

On 16-12-17 09:16 PM, Daniel Foerster wrote:

You know, I suppose we could just use GitHub pages.

On Dec 17, 2016 17:32, "Charles Cossé" > wrote:




On Sat, Dec 17, 2016 at 4:12 PM, Daniel Foerster
> wrote:

Using S3/CloudFront is a lot cheaper than the EC2 setup you're
imagining (and which a Django stack would require).



I never said to use Amazon at all.  Just use the current server,
whatever it is (unless it's Amazon).

On 12/17/2016 05:11 PM, Charles Cossé wrote:

Yikes!  who's gonna pay the Amazon bill?

On Sat, Dec 17, 2016 at 4:09 PM, Paul Vincent Craven
> wrote:

If most of the site is static, then I think Django would
be overkill. The static portion of the site can easily be
deployed via Amazon S3/CloudFront and then we'd not have
to maintain a server.

Paul Vincent Craven

On Sat, Dec 17, 2016 at 5:00 PM, Charles Cossé
> wrote:


On Sat, Dec 17, 2016 at 3:26 PM, Thomas Kluyver
> wrote:


So far, I think the proposals for the static
information part of the site are Nikola (a static
site generator oriented around blogs) and Sphinx
(oriented around docs). Both are written in
Python. Does anyone want to make the case for any
other system?


Can Django factor-in there? I guess it would reside
underneathe the other pkgs ... but might as well run
Python through-and-through imho.





--
Linkedin  |
E-Learning 







--
Linkedin  | E-Learning











Re: [pygame] New pygame.org website

2016-12-18 Thread Richie Ward
Use https://www.webfaction.com to host a python website. They are cheaper
than a VPS and they support mod_wsgi natively. Hosted on SSD with powerful
processor, so it will handle traffic easy.

On 18 Dec 2016 11:23, "Radomir Dopieralski"  wrote:

> As far as I can tell, they come from Disqus. Since i have it blocked, I
> didn't see them either.
>
> On Sun, 18 Dec 2016 10:36:56 +
> Thomas Kluyver  wrote:
>
> > Yuck. I always use an adblocker, so I hadn't seen the 'sponsored
> > links' until now. I agree that they're hideous, and we definitely
> > shouldn't have them on the new site. I wonder if they were put on
> > there deliberately, or if the site has been compromised.
> >
> > On 18 December 2016 at 09:42, Charles Cossé  wrote:
> >
> > > Would it be possible to eliminate those unsightly "sponsored links"
> > > advertisements going forward?
> > > I just logged-in for first time in 2 years and there's Donald Trump
> > > and Angelina Jolie on my project page
> > >  ...
> > > yikes!
> > >
> > > On Sun, Dec 18, 2016 at 1:58 AM, Thomas Kluyver 
> > > wrote:
> > >> It doesn't look like bitbucket sites support custom domains, so if
> > >> we want it to become pygame.org, we'd have to host it on github
> > >> rather than bitbucket. Gh does support bringing your own domain.
> > >>
> > >> On 18 Dec 2016 8:49 a.m., "Thomas Kluyver" 
> > >> wrote:
> > >>> There are a couple of things being discussed that I think have
> > >>> easy answers.
> > >>>
> > >>> Docs will remain in sphinx, whatever we do with the rest of the
> > >>> website. They're already using sphinx, and Nikola/Pelican are not
> > >>> decent alternatives for that part.
> > >>>
> > >>> Hosting for the static part will be on github pages or bitbucket.
> > >>> Free hosting is one of the key advantages of a static site. I've
> > >>> used both of these for web sites before.
> > >>>
> > >>>
> > >>> On 18 Dec 2016 7:02 a.m., "Lenard Lindstrom" 
> > >>> wrote:
> >  I was looking at Pelican: http://blog.getpelican.com/
> > 
> >  It looks like Sphinx lite for web sites. Page content can be
> >  reST, Markdown, or AsciiDoc. Jinja templates are used for page
> >  generation.
> > 
> >  On 16-12-17 02:26 PM, Thomas Kluyver wrote:
> > 
> > >
> > >
> > > So far, I think the proposals for the static information part
> > > of the site are Nikola (a static site generator oriented around
> > > blogs) and Sphinx (oriented around docs). Both are written in
> > > Python. Does anyone want to make the case for any other system?
> > >
> > >
> > 
> > >
> > >
> > > --
> > >
> > > Linkedin  | E-Learning
> > > 
> > >
> > >
> > >
>
>
>
> --
> Radomir Dopieralski
>
> --
> Radomir Dopieralski
>


Re: [pygame] New pygame.org website

2016-12-18 Thread Radomir Dopieralski
As far as I can tell, they come from Disqus. Since i have it blocked, I
didn't see them either.

On Sun, 18 Dec 2016 10:36:56 +
Thomas Kluyver  wrote:

> Yuck. I always use an adblocker, so I hadn't seen the 'sponsored
> links' until now. I agree that they're hideous, and we definitely
> shouldn't have them on the new site. I wonder if they were put on
> there deliberately, or if the site has been compromised.
> 
> On 18 December 2016 at 09:42, Charles Cossé  wrote:
> 
> > Would it be possible to eliminate those unsightly "sponsored links"
> > advertisements going forward?
> > I just logged-in for first time in 2 years and there's Donald Trump
> > and Angelina Jolie on my project page
> >  ...
> > yikes!
> >
> > On Sun, Dec 18, 2016 at 1:58 AM, Thomas Kluyver 
> > wrote: 
> >> It doesn't look like bitbucket sites support custom domains, so if
> >> we want it to become pygame.org, we'd have to host it on github
> >> rather than bitbucket. Gh does support bringing your own domain.
> >>
> >> On 18 Dec 2016 8:49 a.m., "Thomas Kluyver" 
> >> wrote: 
> >>> There are a couple of things being discussed that I think have
> >>> easy answers.
> >>>
> >>> Docs will remain in sphinx, whatever we do with the rest of the
> >>> website. They're already using sphinx, and Nikola/Pelican are not
> >>> decent alternatives for that part.
> >>>
> >>> Hosting for the static part will be on github pages or bitbucket.
> >>> Free hosting is one of the key advantages of a static site. I've
> >>> used both of these for web sites before.
> >>>
> >>>
> >>> On 18 Dec 2016 7:02 a.m., "Lenard Lindstrom" 
> >>> wrote: 
>  I was looking at Pelican: http://blog.getpelican.com/
> 
>  It looks like Sphinx lite for web sites. Page content can be
>  reST, Markdown, or AsciiDoc. Jinja templates are used for page
>  generation.
> 
>  On 16-12-17 02:26 PM, Thomas Kluyver wrote:
>   
> >
> >
> > So far, I think the proposals for the static information part
> > of the site are Nikola (a static site generator oriented around
> > blogs) and Sphinx (oriented around docs). Both are written in
> > Python. Does anyone want to make the case for any other system?
> >
> >  
>   
> >
> >
> > --
> >
> > Linkedin  | E-Learning
> > 
> >
> >
> >  



-- 
Radomir Dopieralski

-- 
Radomir Dopieralski


Re: [pygame] New pygame.org website

2016-12-18 Thread Thomas Kluyver
Ah, the 'sponsored links' are coming from the Disqus comment service.
That's disappointing, I thought they were better than that. If that's the
price of Disqus comments,  I think we should avoid using them.

On 18 December 2016 at 10:36, Thomas Kluyver  wrote:

> Yuck. I always use an adblocker, so I hadn't seen the 'sponsored links'
> until now. I agree that they're hideous, and we definitely shouldn't have
> them on the new site. I wonder if they were put on there deliberately, or
> if the site has been compromised.
>
> On 18 December 2016 at 09:42, Charles Cossé  wrote:
>
>> Would it be possible to eliminate those unsightly "sponsored links"
>> advertisements going forward?
>> I just logged-in for first time in 2 years and there's Donald Trump and
>> Angelina Jolie on my project page
>>  ... yikes!
>>
>> On Sun, Dec 18, 2016 at 1:58 AM, Thomas Kluyver  wrote:
>>
>>> It doesn't look like bitbucket sites support custom domains, so if we
>>> want it to become pygame.org, we'd have to host it on github rather
>>> than bitbucket. Gh does support bringing your own domain.
>>>
>>> On 18 Dec 2016 8:49 a.m., "Thomas Kluyver"  wrote:
>>>
 There are a couple of things being discussed that I think have easy
 answers.

 Docs will remain in sphinx, whatever we do with the rest of the
 website. They're already using sphinx, and Nikola/Pelican are not decent
 alternatives for that part.

 Hosting for the static part will be on github pages or bitbucket. Free
 hosting is one of the key advantages of a static site. I've used both of
 these for web sites before.


 On 18 Dec 2016 7:02 a.m., "Lenard Lindstrom"  wrote:

> I was looking at Pelican: http://blog.getpelican.com/
>
> It looks like Sphinx lite for web sites. Page content can be reST,
> Markdown, or AsciiDoc. Jinja templates are used for page generation.
>
> On 16-12-17 02:26 PM, Thomas Kluyver wrote:
>
>>
>>
>> So far, I think the proposals for the static information part of the
>> site are Nikola (a static site generator oriented around blogs) and 
>> Sphinx
>> (oriented around docs). Both are written in Python. Does anyone want to
>> make the case for any other system?
>>
>>
>
>>
>>
>> --
>>
>> Linkedin  | E-Learning
>> 
>>
>>
>>
>


Re: [pygame] New pygame.org website

2016-12-18 Thread Thomas Kluyver
Yuck. I always use an adblocker, so I hadn't seen the 'sponsored links'
until now. I agree that they're hideous, and we definitely shouldn't have
them on the new site. I wonder if they were put on there deliberately, or
if the site has been compromised.

On 18 December 2016 at 09:42, Charles Cossé  wrote:

> Would it be possible to eliminate those unsightly "sponsored links"
> advertisements going forward?
> I just logged-in for first time in 2 years and there's Donald Trump and
> Angelina Jolie on my project page
>  ... yikes!
>
> On Sun, Dec 18, 2016 at 1:58 AM, Thomas Kluyver  wrote:
>
>> It doesn't look like bitbucket sites support custom domains, so if we
>> want it to become pygame.org, we'd have to host it on github rather than
>> bitbucket. Gh does support bringing your own domain.
>>
>> On 18 Dec 2016 8:49 a.m., "Thomas Kluyver"  wrote:
>>
>>> There are a couple of things being discussed that I think have easy
>>> answers.
>>>
>>> Docs will remain in sphinx, whatever we do with the rest of the website.
>>> They're already using sphinx, and Nikola/Pelican are not decent
>>> alternatives for that part.
>>>
>>> Hosting for the static part will be on github pages or bitbucket. Free
>>> hosting is one of the key advantages of a static site. I've used both of
>>> these for web sites before.
>>>
>>>
>>> On 18 Dec 2016 7:02 a.m., "Lenard Lindstrom"  wrote:
>>>
 I was looking at Pelican: http://blog.getpelican.com/

 It looks like Sphinx lite for web sites. Page content can be reST,
 Markdown, or AsciiDoc. Jinja templates are used for page generation.

 On 16-12-17 02:26 PM, Thomas Kluyver wrote:

>
>
> So far, I think the proposals for the static information part of the
> site are Nikola (a static site generator oriented around blogs) and Sphinx
> (oriented around docs). Both are written in Python. Does anyone want to
> make the case for any other system?
>
>

>
>
> --
>
> Linkedin  | E-Learning
> 
>
>
>


Re: [pygame] New pygame.org website

2016-12-18 Thread Thomas Kluyver
It doesn't look like bitbucket sites support custom domains, so if we want
it to become pygame.org, we'd have to host it on github rather than
bitbucket. Gh does support bringing your own domain.

On 18 Dec 2016 8:49 a.m., "Thomas Kluyver"  wrote:

> There are a couple of things being discussed that I think have easy
> answers.
>
> Docs will remain in sphinx, whatever we do with the rest of the website.
> They're already using sphinx, and Nikola/Pelican are not decent
> alternatives for that part.
>
> Hosting for the static part will be on github pages or bitbucket. Free
> hosting is one of the key advantages of a static site. I've used both of
> these for web sites before.
>
>
> On 18 Dec 2016 7:02 a.m., "Lenard Lindstrom"  wrote:
>
>> I was looking at Pelican: http://blog.getpelican.com/
>>
>> It looks like Sphinx lite for web sites. Page content can be reST,
>> Markdown, or AsciiDoc. Jinja templates are used for page generation.
>>
>> On 16-12-17 02:26 PM, Thomas Kluyver wrote:
>>
>>>
>>>
>>> So far, I think the proposals for the static information part of the
>>> site are Nikola (a static site generator oriented around blogs) and Sphinx
>>> (oriented around docs). Both are written in Python. Does anyone want to
>>> make the case for any other system?
>>>
>>>
>>


Re: [pygame] New pygame.org website

2016-12-18 Thread Thomas Kluyver
There are a couple of things being discussed that I think have easy answers.

Docs will remain in sphinx, whatever we do with the rest of the website.
They're already using sphinx, and Nikola/Pelican are not decent
alternatives for that part.

Hosting for the static part will be on github pages or bitbucket. Free
hosting is one of the key advantages of a static site. I've used both of
these for web sites before.


On 18 Dec 2016 7:02 a.m., "Lenard Lindstrom"  wrote:

> I was looking at Pelican: http://blog.getpelican.com/
>
> It looks like Sphinx lite for web sites. Page content can be reST,
> Markdown, or AsciiDoc. Jinja templates are used for page generation.
>
> On 16-12-17 02:26 PM, Thomas Kluyver wrote:
>
>>
>>
>> So far, I think the proposals for the static information part of the site
>> are Nikola (a static site generator oriented around blogs) and Sphinx
>> (oriented around docs). Both are written in Python. Does anyone want to
>> make the case for any other system?
>>
>>
>


Re: [pygame] New pygame.org website

2016-12-17 Thread Lenard Lindstrom

I was looking at Pelican: http://blog.getpelican.com/

It looks like Sphinx lite for web sites. Page content can be reST, 
Markdown, or AsciiDoc. Jinja templates are used for page generation.


On 16-12-17 02:26 PM, Thomas Kluyver wrote:



So far, I think the proposals for the static information part of the 
site are Nikola (a static site generator oriented around blogs) and 
Sphinx (oriented around docs). Both are written in Python. Does anyone 
want to make the case for any other system?






Re: [pygame] New pygame.org website

2016-12-17 Thread Lenard Lindstrom
Bitbucket also has static web site support. I set one up for the Pygame 
docs awhile ago, but have not maintained it:


http://pygame.bitbucket.org/docs/pygame/

The repository is here:

https://bitbucket.org/pygame/pygame.bitbucket.org

Lenard Lindstrom

On 16-12-17 09:16 PM, Daniel Foerster wrote:

You know, I suppose we could just use GitHub pages.

On Dec 17, 2016 17:32, "Charles Cossé" > wrote:




On Sat, Dec 17, 2016 at 4:12 PM, Daniel Foerster
> wrote:

Using S3/CloudFront is a lot cheaper than the EC2 setup you're
imagining (and which a Django stack would require).



I never said to use Amazon at all.  Just use the current server,
whatever it is (unless it's Amazon).

On 12/17/2016 05:11 PM, Charles Cossé wrote:

Yikes!  who's gonna pay the Amazon bill?

On Sat, Dec 17, 2016 at 4:09 PM, Paul Vincent Craven
> wrote:

If most of the site is static, then I think Django would
be overkill. The static portion of the site can easily be
deployed via Amazon S3/CloudFront and then we'd not have
to maintain a server.

Paul Vincent Craven

On Sat, Dec 17, 2016 at 5:00 PM, Charles Cossé
> wrote:


On Sat, Dec 17, 2016 at 3:26 PM, Thomas Kluyver
> wrote:


So far, I think the proposals for the static
information part of the site are Nikola (a static
site generator oriented around blogs) and Sphinx
(oriented around docs). Both are written in
Python. Does anyone want to make the case for any
other system?


Can Django factor-in there? I guess it would reside
underneathe the other pkgs ... but might as well run
Python through-and-through imho.





-- 


Linkedin  |
E-Learning 







-- 


Linkedin  | E-Learning








Re: [pygame] New pygame.org website

2016-12-17 Thread Daniel Foerster
I'd suggest contacting GitHub to see if there's any way we could get
control of that group.

On Dec 16, 2016 11:59, "Thomas Kluyver"  wrote:

Does anyone know who owns the pygame organisation on Github? It's claimed
but not in use.


Re: [pygame] New pygame.org website

2016-12-17 Thread DiliupG
ok. sorry if i was a bother. :)

On Sun, Dec 18, 2016 at 11:06 AM, Daniel Foerster 
wrote:

> As has been noted previously, the game project uploads are a separate
> issue from the rest of the site.
>
> On Dec 17, 2016 23:32, "DiliupG"  wrote:
>
>> but how will new people upload their games unless they learn how to?
>>
>> On Sun, Dec 18, 2016 at 11:00 AM, Daniel Foerster 
>> wrote:
>>
>>> You don't have to know how GitHub Pages works to use the site, and if
>>> we're putting the repo on GitHub, contributors will have to know a little
>>> about GitHub and git regardless.
>>>
>>> On Dec 17, 2016 23:19, "DiliupG"  wrote:
>>>
 not everyone understands how github works.

 On Sun, Dec 18, 2016 at 10:46 AM, Daniel Foerster 
 wrote:

> You know, I suppose we could just use GitHub pages.
>
> On Dec 17, 2016 17:32, "Charles Cossé"  wrote:
>
>
>
> On Sat, Dec 17, 2016 at 4:12 PM, Daniel Foerster 
> wrote:
>
>> Using S3/CloudFront is a lot cheaper than the EC2 setup you're
>> imagining (and which a Django stack would require).
>>
>>
> I never said to use Amazon at all.  Just use the current server,
> whatever it is (unless it's Amazon).
>
>
>
>> On 12/17/2016 05:11 PM, Charles Cossé wrote:
>>
>> Yikes!  who's gonna pay the Amazon bill?
>>
>> On Sat, Dec 17, 2016 at 4:09 PM, Paul Vincent Craven <
>> p...@cravenfamily.com> wrote:
>>
>>> If most of the site is static, then I think Django would be
>>> overkill. The static portion of the site can easily be deployed via 
>>> Amazon
>>> S3/CloudFront and then we'd not have to maintain a server.
>>>
>>> Paul Vincent Craven
>>>
>>> On Sat, Dec 17, 2016 at 5:00 PM, Charles Cossé 
>>> wrote:
>>>

 On Sat, Dec 17, 2016 at 3:26 PM, Thomas Kluyver 
 wrote:

>
> So far, I think the proposals for the static information part of
> the site are Nikola (a static site generator oriented around blogs) 
> and
> Sphinx (oriented around docs). Both are written in Python. Does 
> anyone want
> to make the case for any other system?
>
>
 Can Django factor-in there?  I guess it would reside underneathe
 the other pkgs ... but might as well run Python through-and-through 
 imho.


>>>
>>
>>
>> --
>>
>> Linkedin  | E-Learning
>> 
>>
>>
>>
>>
>
>
> --
>
> Linkedin  | E-Learning
> 
>
>
>
>


 --
 Kalasuri Diliup Gabadamudalige

 https://dahamgatalu.wordpress.com/
 http://soft.diliupg.com/
 http://www.diliupg.com

 
 **
 This e-mail is confidential. It may also be legally privileged. If you
 are not the intended recipient or have received it in error, please delete
 it and all copies from your system and notify the sender immediately by
 return e-mail. Any unauthorized reading, reproducing, printing or further
 dissemination of this e-mail or its contents is strictly prohibited and may
 be unlawful. Internet communications cannot be guaranteed to be timely,
 secure, error or virus-free. The sender does not accept liability for any
 errors or omissions.
 
 **


>>
>>
>> --
>> Kalasuri Diliup Gabadamudalige
>>
>> https://dahamgatalu.wordpress.com/
>> http://soft.diliupg.com/
>> http://www.diliupg.com
>>
>> 
>> **
>> This e-mail is confidential. It may also be legally privileged. If you
>> are not the intended recipient or have received it in error, please delete
>> it and all copies from your system and notify the sender immediately by
>> return e-mail. Any unauthorized reading, reproducing, printing or further
>> dissemination of this e-mail or its contents is strictly prohibited and may
>> be unlawful. Internet communications cannot be guaranteed to be timely,
>> secure, error or virus-free. The sender does not accept liability for any
>> errors or omissions.
>> 
>> **
>>
>>


-- 
Kalasuri Diliup Gabadamudalige

https://dahamgatalu.wordpress.com/
http://soft.diliupg.com/
http://www.diliupg.com


Re: [pygame] New pygame.org website

2016-12-17 Thread Daniel Foerster
As has been noted previously, the game project uploads are a separate issue
from the rest of the site.

On Dec 17, 2016 23:32, "DiliupG"  wrote:

> but how will new people upload their games unless they learn how to?
>
> On Sun, Dec 18, 2016 at 11:00 AM, Daniel Foerster 
> wrote:
>
>> You don't have to know how GitHub Pages works to use the site, and if
>> we're putting the repo on GitHub, contributors will have to know a little
>> about GitHub and git regardless.
>>
>> On Dec 17, 2016 23:19, "DiliupG"  wrote:
>>
>>> not everyone understands how github works.
>>>
>>> On Sun, Dec 18, 2016 at 10:46 AM, Daniel Foerster 
>>> wrote:
>>>
 You know, I suppose we could just use GitHub pages.

 On Dec 17, 2016 17:32, "Charles Cossé"  wrote:



 On Sat, Dec 17, 2016 at 4:12 PM, Daniel Foerster 
 wrote:

> Using S3/CloudFront is a lot cheaper than the EC2 setup you're
> imagining (and which a Django stack would require).
>
>
 I never said to use Amazon at all.  Just use the current server,
 whatever it is (unless it's Amazon).



> On 12/17/2016 05:11 PM, Charles Cossé wrote:
>
> Yikes!  who's gonna pay the Amazon bill?
>
> On Sat, Dec 17, 2016 at 4:09 PM, Paul Vincent Craven <
> p...@cravenfamily.com> wrote:
>
>> If most of the site is static, then I think Django would be overkill.
>> The static portion of the site can easily be deployed via Amazon
>> S3/CloudFront and then we'd not have to maintain a server.
>>
>> Paul Vincent Craven
>>
>> On Sat, Dec 17, 2016 at 5:00 PM, Charles Cossé 
>> wrote:
>>
>>>
>>> On Sat, Dec 17, 2016 at 3:26 PM, Thomas Kluyver 
>>> wrote:
>>>

 So far, I think the proposals for the static information part of
 the site are Nikola (a static site generator oriented around blogs) and
 Sphinx (oriented around docs). Both are written in Python. Does anyone 
 want
 to make the case for any other system?


>>> Can Django factor-in there?  I guess it would reside underneathe the
>>> other pkgs ... but might as well run Python through-and-through imho.
>>>
>>>
>>
>
>
> --
>
> Linkedin  | E-Learning
> 
>
>
>
>


 --

 Linkedin  | E-Learning
 




>>>
>>>
>>> --
>>> Kalasuri Diliup Gabadamudalige
>>>
>>> https://dahamgatalu.wordpress.com/
>>> http://soft.diliupg.com/
>>> http://www.diliupg.com
>>>
>>> 
>>> **
>>> This e-mail is confidential. It may also be legally privileged. If you
>>> are not the intended recipient or have received it in error, please delete
>>> it and all copies from your system and notify the sender immediately by
>>> return e-mail. Any unauthorized reading, reproducing, printing or further
>>> dissemination of this e-mail or its contents is strictly prohibited and may
>>> be unlawful. Internet communications cannot be guaranteed to be timely,
>>> secure, error or virus-free. The sender does not accept liability for any
>>> errors or omissions.
>>> 
>>> **
>>>
>>>
>
>
> --
> Kalasuri Diliup Gabadamudalige
>
> https://dahamgatalu.wordpress.com/
> http://soft.diliupg.com/
> http://www.diliupg.com
>
> 
> **
> This e-mail is confidential. It may also be legally privileged. If you are
> not the intended recipient or have received it in error, please delete it
> and all copies from your system and notify the sender immediately by return
> e-mail. Any unauthorized reading, reproducing, printing or further
> dissemination of this e-mail or its contents is strictly prohibited and may
> be unlawful. Internet communications cannot be guaranteed to be timely,
> secure, error or virus-free. The sender does not accept liability for any
> errors or omissions.
> 
> **
>
>


Re: [pygame] New pygame.org website

2016-12-17 Thread DiliupG
but how will new people upload their games unless they learn how to?

On Sun, Dec 18, 2016 at 11:00 AM, Daniel Foerster 
wrote:

> You don't have to know how GitHub Pages works to use the site, and if
> we're putting the repo on GitHub, contributors will have to know a little
> about GitHub and git regardless.
>
> On Dec 17, 2016 23:19, "DiliupG"  wrote:
>
>> not everyone understands how github works.
>>
>> On Sun, Dec 18, 2016 at 10:46 AM, Daniel Foerster 
>> wrote:
>>
>>> You know, I suppose we could just use GitHub pages.
>>>
>>> On Dec 17, 2016 17:32, "Charles Cossé"  wrote:
>>>
>>>
>>>
>>> On Sat, Dec 17, 2016 at 4:12 PM, Daniel Foerster 
>>> wrote:
>>>
 Using S3/CloudFront is a lot cheaper than the EC2 setup you're
 imagining (and which a Django stack would require).


>>> I never said to use Amazon at all.  Just use the current server,
>>> whatever it is (unless it's Amazon).
>>>
>>>
>>>
 On 12/17/2016 05:11 PM, Charles Cossé wrote:

 Yikes!  who's gonna pay the Amazon bill?

 On Sat, Dec 17, 2016 at 4:09 PM, Paul Vincent Craven <
 p...@cravenfamily.com> wrote:

> If most of the site is static, then I think Django would be overkill.
> The static portion of the site can easily be deployed via Amazon
> S3/CloudFront and then we'd not have to maintain a server.
>
> Paul Vincent Craven
>
> On Sat, Dec 17, 2016 at 5:00 PM, Charles Cossé 
> wrote:
>
>>
>> On Sat, Dec 17, 2016 at 3:26 PM, Thomas Kluyver 
>> wrote:
>>
>>>
>>> So far, I think the proposals for the static information part of the
>>> site are Nikola (a static site generator oriented around blogs) and 
>>> Sphinx
>>> (oriented around docs). Both are written in Python. Does anyone want to
>>> make the case for any other system?
>>>
>>>
>> Can Django factor-in there?  I guess it would reside underneathe the
>> other pkgs ... but might as well run Python through-and-through imho.
>>
>>
>


 --

 Linkedin  | E-Learning
 




>>>
>>>
>>> --
>>>
>>> Linkedin  | E-Learning
>>> 
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Kalasuri Diliup Gabadamudalige
>>
>> https://dahamgatalu.wordpress.com/
>> http://soft.diliupg.com/
>> http://www.diliupg.com
>>
>> 
>> **
>> This e-mail is confidential. It may also be legally privileged. If you
>> are not the intended recipient or have received it in error, please delete
>> it and all copies from your system and notify the sender immediately by
>> return e-mail. Any unauthorized reading, reproducing, printing or further
>> dissemination of this e-mail or its contents is strictly prohibited and may
>> be unlawful. Internet communications cannot be guaranteed to be timely,
>> secure, error or virus-free. The sender does not accept liability for any
>> errors or omissions.
>> 
>> **
>>
>>


-- 
Kalasuri Diliup Gabadamudalige

https://dahamgatalu.wordpress.com/
http://soft.diliupg.com/
http://www.diliupg.com

**
This e-mail is confidential. It may also be legally privileged. If you are
not the intended recipient or have received it in error, please delete it
and all copies from your system and notify the sender immediately by return
e-mail. Any unauthorized reading, reproducing, printing or further
dissemination of this e-mail or its contents is strictly prohibited and may
be unlawful. Internet communications cannot be guaranteed to be timely,
secure, error or virus-free. The sender does not accept liability for any
errors or omissions.
**


Re: [pygame] New pygame.org website

2016-12-17 Thread Daniel Foerster
We can use GitHub Pages without using Jekyll.

On Dec 17, 2016 23:27, "Paul Vincent Craven"  wrote:

> I haven't figured out Jekyll. But if someone wants to start it, that's
> fine. I think because API doc's are built in Sphinx that a similar tool
> might be wise. Still kind of like Nikola if I can figure out how to get
> started.
>
> On Dec 17, 2016 11:19 PM, "DiliupG"  wrote:
>
>> not everyone understands how github works.
>>
>> On Sun, Dec 18, 2016 at 10:46 AM, Daniel Foerster 
>> wrote:
>>
>>> You know, I suppose we could just use GitHub pages.
>>>
>>> On Dec 17, 2016 17:32, "Charles Cossé"  wrote:
>>>
>>>
>>>
>>> On Sat, Dec 17, 2016 at 4:12 PM, Daniel Foerster 
>>> wrote:
>>>
 Using S3/CloudFront is a lot cheaper than the EC2 setup you're
 imagining (and which a Django stack would require).


>>> I never said to use Amazon at all.  Just use the current server,
>>> whatever it is (unless it's Amazon).
>>>
>>>
>>>
 On 12/17/2016 05:11 PM, Charles Cossé wrote:

 Yikes!  who's gonna pay the Amazon bill?

 On Sat, Dec 17, 2016 at 4:09 PM, Paul Vincent Craven <
 p...@cravenfamily.com> wrote:

> If most of the site is static, then I think Django would be overkill.
> The static portion of the site can easily be deployed via Amazon
> S3/CloudFront and then we'd not have to maintain a server.
>
> Paul Vincent Craven
>
> On Sat, Dec 17, 2016 at 5:00 PM, Charles Cossé 
> wrote:
>
>>
>> On Sat, Dec 17, 2016 at 3:26 PM, Thomas Kluyver 
>> wrote:
>>
>>>
>>> So far, I think the proposals for the static information part of the
>>> site are Nikola (a static site generator oriented around blogs) and 
>>> Sphinx
>>> (oriented around docs). Both are written in Python. Does anyone want to
>>> make the case for any other system?
>>>
>>>
>> Can Django factor-in there?  I guess it would reside underneathe the
>> other pkgs ... but might as well run Python through-and-through imho.
>>
>>
>


 --

 Linkedin  | E-Learning
 




>>>
>>>
>>> --
>>>
>>> Linkedin  | E-Learning
>>> 
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Kalasuri Diliup Gabadamudalige
>>
>> https://dahamgatalu.wordpress.com/
>> http://soft.diliupg.com/
>> http://www.diliupg.com
>>
>> 
>> **
>> This e-mail is confidential. It may also be legally privileged. If you
>> are not the intended recipient or have received it in error, please delete
>> it and all copies from your system and notify the sender immediately by
>> return e-mail. Any unauthorized reading, reproducing, printing or further
>> dissemination of this e-mail or its contents is strictly prohibited and may
>> be unlawful. Internet communications cannot be guaranteed to be timely,
>> secure, error or virus-free. The sender does not accept liability for any
>> errors or omissions.
>> 
>> **
>>
>>


Re: [pygame] New pygame.org website

2016-12-17 Thread Daniel Foerster
You don't have to know how GitHub Pages works to use the site, and if we're
putting the repo on GitHub, contributors will have to know a little about
GitHub and git regardless.

On Dec 17, 2016 23:19, "DiliupG"  wrote:

> not everyone understands how github works.
>
> On Sun, Dec 18, 2016 at 10:46 AM, Daniel Foerster 
> wrote:
>
>> You know, I suppose we could just use GitHub pages.
>>
>> On Dec 17, 2016 17:32, "Charles Cossé"  wrote:
>>
>>
>>
>> On Sat, Dec 17, 2016 at 4:12 PM, Daniel Foerster 
>> wrote:
>>
>>> Using S3/CloudFront is a lot cheaper than the EC2 setup you're imagining
>>> (and which a Django stack would require).
>>>
>>>
>> I never said to use Amazon at all.  Just use the current server, whatever
>> it is (unless it's Amazon).
>>
>>
>>
>>> On 12/17/2016 05:11 PM, Charles Cossé wrote:
>>>
>>> Yikes!  who's gonna pay the Amazon bill?
>>>
>>> On Sat, Dec 17, 2016 at 4:09 PM, Paul Vincent Craven <
>>> p...@cravenfamily.com> wrote:
>>>
 If most of the site is static, then I think Django would be overkill.
 The static portion of the site can easily be deployed via Amazon
 S3/CloudFront and then we'd not have to maintain a server.

 Paul Vincent Craven

 On Sat, Dec 17, 2016 at 5:00 PM, Charles Cossé 
 wrote:

>
> On Sat, Dec 17, 2016 at 3:26 PM, Thomas Kluyver 
> wrote:
>
>>
>> So far, I think the proposals for the static information part of the
>> site are Nikola (a static site generator oriented around blogs) and 
>> Sphinx
>> (oriented around docs). Both are written in Python. Does anyone want to
>> make the case for any other system?
>>
>>
> Can Django factor-in there?  I guess it would reside underneathe the
> other pkgs ... but might as well run Python through-and-through imho.
>
>

>>>
>>>
>>> --
>>>
>>> Linkedin  | E-Learning
>>> 
>>>
>>>
>>>
>>>
>>
>>
>> --
>>
>> Linkedin  | E-Learning
>> 
>>
>>
>>
>>
>
>
> --
> Kalasuri Diliup Gabadamudalige
>
> https://dahamgatalu.wordpress.com/
> http://soft.diliupg.com/
> http://www.diliupg.com
>
> 
> **
> This e-mail is confidential. It may also be legally privileged. If you are
> not the intended recipient or have received it in error, please delete it
> and all copies from your system and notify the sender immediately by return
> e-mail. Any unauthorized reading, reproducing, printing or further
> dissemination of this e-mail or its contents is strictly prohibited and may
> be unlawful. Internet communications cannot be guaranteed to be timely,
> secure, error or virus-free. The sender does not accept liability for any
> errors or omissions.
> 
> **
>
>


Re: [pygame] New pygame.org website

2016-12-17 Thread Paul Vincent Craven
I haven't figured out Jekyll. But if someone wants to start it, that's
fine. I think because API doc's are built in Sphinx that a similar tool
might be wise. Still kind of like Nikola if I can figure out how to get
started.

On Dec 17, 2016 11:19 PM, "DiliupG"  wrote:

> not everyone understands how github works.
>
> On Sun, Dec 18, 2016 at 10:46 AM, Daniel Foerster 
> wrote:
>
>> You know, I suppose we could just use GitHub pages.
>>
>> On Dec 17, 2016 17:32, "Charles Cossé"  wrote:
>>
>>
>>
>> On Sat, Dec 17, 2016 at 4:12 PM, Daniel Foerster 
>> wrote:
>>
>>> Using S3/CloudFront is a lot cheaper than the EC2 setup you're imagining
>>> (and which a Django stack would require).
>>>
>>>
>> I never said to use Amazon at all.  Just use the current server, whatever
>> it is (unless it's Amazon).
>>
>>
>>
>>> On 12/17/2016 05:11 PM, Charles Cossé wrote:
>>>
>>> Yikes!  who's gonna pay the Amazon bill?
>>>
>>> On Sat, Dec 17, 2016 at 4:09 PM, Paul Vincent Craven <
>>> p...@cravenfamily.com> wrote:
>>>
 If most of the site is static, then I think Django would be overkill.
 The static portion of the site can easily be deployed via Amazon
 S3/CloudFront and then we'd not have to maintain a server.

 Paul Vincent Craven

 On Sat, Dec 17, 2016 at 5:00 PM, Charles Cossé 
 wrote:

>
> On Sat, Dec 17, 2016 at 3:26 PM, Thomas Kluyver 
> wrote:
>
>>
>> So far, I think the proposals for the static information part of the
>> site are Nikola (a static site generator oriented around blogs) and 
>> Sphinx
>> (oriented around docs). Both are written in Python. Does anyone want to
>> make the case for any other system?
>>
>>
> Can Django factor-in there?  I guess it would reside underneathe the
> other pkgs ... but might as well run Python through-and-through imho.
>
>

>>>
>>>
>>> --
>>>
>>> Linkedin  | E-Learning
>>> 
>>>
>>>
>>>
>>>
>>
>>
>> --
>>
>> Linkedin  | E-Learning
>> 
>>
>>
>>
>>
>
>
> --
> Kalasuri Diliup Gabadamudalige
>
> https://dahamgatalu.wordpress.com/
> http://soft.diliupg.com/
> http://www.diliupg.com
>
> 
> **
> This e-mail is confidential. It may also be legally privileged. If you are
> not the intended recipient or have received it in error, please delete it
> and all copies from your system and notify the sender immediately by return
> e-mail. Any unauthorized reading, reproducing, printing or further
> dissemination of this e-mail or its contents is strictly prohibited and may
> be unlawful. Internet communications cannot be guaranteed to be timely,
> secure, error or virus-free. The sender does not accept liability for any
> errors or omissions.
> 
> **
>
>


Re: [pygame] New pygame.org website

2016-12-17 Thread DiliupG
not everyone understands how github works.

On Sun, Dec 18, 2016 at 10:46 AM, Daniel Foerster 
wrote:

> You know, I suppose we could just use GitHub pages.
>
> On Dec 17, 2016 17:32, "Charles Cossé"  wrote:
>
>
>
> On Sat, Dec 17, 2016 at 4:12 PM, Daniel Foerster 
> wrote:
>
>> Using S3/CloudFront is a lot cheaper than the EC2 setup you're imagining
>> (and which a Django stack would require).
>>
>>
> I never said to use Amazon at all.  Just use the current server, whatever
> it is (unless it's Amazon).
>
>
>
>> On 12/17/2016 05:11 PM, Charles Cossé wrote:
>>
>> Yikes!  who's gonna pay the Amazon bill?
>>
>> On Sat, Dec 17, 2016 at 4:09 PM, Paul Vincent Craven <
>> p...@cravenfamily.com> wrote:
>>
>>> If most of the site is static, then I think Django would be overkill.
>>> The static portion of the site can easily be deployed via Amazon
>>> S3/CloudFront and then we'd not have to maintain a server.
>>>
>>> Paul Vincent Craven
>>>
>>> On Sat, Dec 17, 2016 at 5:00 PM, Charles Cossé  wrote:
>>>

 On Sat, Dec 17, 2016 at 3:26 PM, Thomas Kluyver 
 wrote:

>
> So far, I think the proposals for the static information part of the
> site are Nikola (a static site generator oriented around blogs) and Sphinx
> (oriented around docs). Both are written in Python. Does anyone want to
> make the case for any other system?
>
>
 Can Django factor-in there?  I guess it would reside underneathe the
 other pkgs ... but might as well run Python through-and-through imho.


>>>
>>
>>
>> --
>>
>> Linkedin  | E-Learning
>> 
>>
>>
>>
>>
>
>
> --
>
> Linkedin  | E-Learning
> 
>
>
>
>


-- 
Kalasuri Diliup Gabadamudalige

https://dahamgatalu.wordpress.com/
http://soft.diliupg.com/
http://www.diliupg.com

**
This e-mail is confidential. It may also be legally privileged. If you are
not the intended recipient or have received it in error, please delete it
and all copies from your system and notify the sender immediately by return
e-mail. Any unauthorized reading, reproducing, printing or further
dissemination of this e-mail or its contents is strictly prohibited and may
be unlawful. Internet communications cannot be guaranteed to be timely,
secure, error or virus-free. The sender does not accept liability for any
errors or omissions.
**


Re: [pygame] New pygame.org website

2016-12-17 Thread Daniel Foerster
You know, I suppose we could just use GitHub pages.

On Dec 17, 2016 17:32, "Charles Cossé"  wrote:



On Sat, Dec 17, 2016 at 4:12 PM, Daniel Foerster 
wrote:

> Using S3/CloudFront is a lot cheaper than the EC2 setup you're imagining
> (and which a Django stack would require).
>
>
I never said to use Amazon at all.  Just use the current server, whatever
it is (unless it's Amazon).



> On 12/17/2016 05:11 PM, Charles Cossé wrote:
>
> Yikes!  who's gonna pay the Amazon bill?
>
> On Sat, Dec 17, 2016 at 4:09 PM, Paul Vincent Craven <
> p...@cravenfamily.com> wrote:
>
>> If most of the site is static, then I think Django would be overkill. The
>> static portion of the site can easily be deployed via Amazon S3/CloudFront
>> and then we'd not have to maintain a server.
>>
>> Paul Vincent Craven
>>
>> On Sat, Dec 17, 2016 at 5:00 PM, Charles Cossé  wrote:
>>
>>>
>>> On Sat, Dec 17, 2016 at 3:26 PM, Thomas Kluyver 
>>> wrote:
>>>

 So far, I think the proposals for the static information part of the
 site are Nikola (a static site generator oriented around blogs) and Sphinx
 (oriented around docs). Both are written in Python. Does anyone want to
 make the case for any other system?


>>> Can Django factor-in there?  I guess it would reside underneathe the
>>> other pkgs ... but might as well run Python through-and-through imho.
>>>
>>>
>>
>
>
> --
>
> Linkedin  | E-Learning
> 
>
>
>
>


-- 

Linkedin  | E-Learning



Re: [pygame] New pygame.org website

2016-12-17 Thread Paul Vincent Craven
Except then it is in a pages subdirectory, and it isn't the same as the
home page.

On Dec 17, 2016 10:23 PM, "Daniel Foerster"  wrote:

> You should just be able to create pages/index.md.
>
> On Dec 17, 2016 19:14, "Paul Vincent Craven" 
> wrote:
>
>> I played around with Nikola. I can't figure out how to change the main
>> page. I can create pages in a /pages directory. Don't know how to modify
>> the main page. The Nikola main site wouldn't be bad to model off of, but
>> I'm not sure how to set that up even though you can click 'view source'.
>> Any experts here with that tool?
>>
>> Paul Vincent Craven
>>
>> On Sat, Dec 17, 2016 at 5:22 PM, Radomir Dopieralski > > wrote:
>>
>>> I think we will want to limit the amount of work necessary, at least at
>>> the start -- that means using the current documentation how it is, with
>>> Sphinx, perhaps with a custom Sphinx theme that makes it consistent
>>> with the rest of the website. Don't fix what is not broken. Let's focus
>>> on the things that really require work, and let's do that first -- I'm
>>> sure there is plenty to do already.
>>>
>>> On Sat, 17 Dec 2016 17:09:03 -0600
>>> Daniel Foerster  wrote:
>>>
>>> > I think the easiest way to go will be to generate markdown or ReST
>>> > files with Sphinx or another tool and use them as input to Nikola.
>>> > Otherwise we have to include the pygame source in the website
>>> > repository, which doesn't seem ideal to me.
>>> >
>>> > — Daniel
>>> >
>>> > On 12/17/2016 04:54 PM, Paul Vincent Craven wrote:
>>> > > Is it possible to get Nikola to build the Pygame docs, or will that
>>> > > have to remain Sphinx based?
>>> > >
>>> > > Paul Vincent Craven
>>> > >
>>> > > On Sat, Dec 17, 2016 at 4:26 PM, Thomas Kluyver >> > > > wrote:
>>> > >
>>> > > On 17 December 2016 at 20:40, Alex Z. >> > > > wrote:
>>> > >
>>> > > More important: I think it would be cool to do a real
>>> > > brainstorming about creative ideas together, as everyone has
>>> > > an own vision and arguments for how the site should be and
>>> > > mail is such a slow medium.
>>> > > Maybe we can do a Skype call, Google hangout or whatever
>>> > > soon so as many people as possible really get involved.
>>> > > However we would need a moderator to structure the call and
>>> > > protocol the answers. I would suggest Thomas, as he has the
>>> > > most experience with pygames history and maintaining its
>>> > > resources.
>>> > >
>>> > >
>>> > > I should make it clear that I have very little experience with
>>> > > maintaining Pygame. I turned up earlier this year to pester
>>> > > people into making a release. But I'm happy to co-ordinate getting
>>> > > this work off the ground. :-)
>>> > >
>>> > > I have my reservations about a video chat: it's hard to include
>>> > > everyone, especially as we're spread across widely spaced time
>>> > > zones. Although email is slower, the asynchronous communications
>>> > > give everyone a chance to weigh in. But if people agree that a
>>> > > video chat would be helpful, I'll try to arrange that.
>>> > >
>>> > > So far, I think the proposals for the static information part of
>>> > > the site are Nikola (a static site generator oriented around
>>> > > blogs) and Sphinx (oriented around docs). Both are written in
>>> > > Python. Does anyone want to make the case for any other system?
>>> > >
>>> > > Summarising ideas on the game feed part:
>>> > > - Maybe it could also be static, so you make a pull request to
>>> > > submit a game
>>> > > - Others said please don't do that, because it's too difficult
>>> > > for game developers
>>> > >   - [I agree with both groups. I wonder if we could make a web
>>> > > form which turns the input into a git commit plus pull
>>> > > request...]
>>> > > - Alternatively, we could populate it with data from other
>>> > > sources; either mechanisms for software generally (PyPI,
>>> > > Openhub), or specific to games (Steam, itch.io ,
>>> > > gamejolt)
>>> > >   - [My thoughts: the general sources don't seem a great fit;
>>> > > it's rare to upload screenshots to these, and even if developers
>>> > > did, we would have to scrape them from free text. Pulling from game
>>> > > stores would mean games have to clear a much higher bar of
>>> > > quality and polish than many of the current entries on the feed.
>>> > > That is up for discussion, but I like the current amateur-friendly
>>> > > feel of the feed. If you just want polished games to play, it
>>> > > wouldn't matter that they're in Python]
>>>
>>>
>>> --
>>> Radomir Dopieralski
>>>
>>
>>


Re: [pygame] New pygame.org website

2016-12-17 Thread Paul Vincent Craven
I played around with Nikola. I can't figure out how to change the main
page. I can create pages in a /pages directory. Don't know how to modify
the main page. The Nikola main site wouldn't be bad to model off of, but
I'm not sure how to set that up even though you can click 'view source'.
Any experts here with that tool?

Paul Vincent Craven

On Sat, Dec 17, 2016 at 5:22 PM, Radomir Dopieralski 
wrote:

> I think we will want to limit the amount of work necessary, at least at
> the start -- that means using the current documentation how it is, with
> Sphinx, perhaps with a custom Sphinx theme that makes it consistent
> with the rest of the website. Don't fix what is not broken. Let's focus
> on the things that really require work, and let's do that first -- I'm
> sure there is plenty to do already.
>
> On Sat, 17 Dec 2016 17:09:03 -0600
> Daniel Foerster  wrote:
>
> > I think the easiest way to go will be to generate markdown or ReST
> > files with Sphinx or another tool and use them as input to Nikola.
> > Otherwise we have to include the pygame source in the website
> > repository, which doesn't seem ideal to me.
> >
> > — Daniel
> >
> > On 12/17/2016 04:54 PM, Paul Vincent Craven wrote:
> > > Is it possible to get Nikola to build the Pygame docs, or will that
> > > have to remain Sphinx based?
> > >
> > > Paul Vincent Craven
> > >
> > > On Sat, Dec 17, 2016 at 4:26 PM, Thomas Kluyver  > > > wrote:
> > >
> > > On 17 December 2016 at 20:40, Alex Z.  > > > wrote:
> > >
> > > More important: I think it would be cool to do a real
> > > brainstorming about creative ideas together, as everyone has
> > > an own vision and arguments for how the site should be and
> > > mail is such a slow medium.
> > > Maybe we can do a Skype call, Google hangout or whatever
> > > soon so as many people as possible really get involved.
> > > However we would need a moderator to structure the call and
> > > protocol the answers. I would suggest Thomas, as he has the
> > > most experience with pygames history and maintaining its
> > > resources.
> > >
> > >
> > > I should make it clear that I have very little experience with
> > > maintaining Pygame. I turned up earlier this year to pester
> > > people into making a release. But I'm happy to co-ordinate getting
> > > this work off the ground. :-)
> > >
> > > I have my reservations about a video chat: it's hard to include
> > > everyone, especially as we're spread across widely spaced time
> > > zones. Although email is slower, the asynchronous communications
> > > give everyone a chance to weigh in. But if people agree that a
> > > video chat would be helpful, I'll try to arrange that.
> > >
> > > So far, I think the proposals for the static information part of
> > > the site are Nikola (a static site generator oriented around
> > > blogs) and Sphinx (oriented around docs). Both are written in
> > > Python. Does anyone want to make the case for any other system?
> > >
> > > Summarising ideas on the game feed part:
> > > - Maybe it could also be static, so you make a pull request to
> > > submit a game
> > > - Others said please don't do that, because it's too difficult
> > > for game developers
> > >   - [I agree with both groups. I wonder if we could make a web
> > > form which turns the input into a git commit plus pull
> > > request...]
> > > - Alternatively, we could populate it with data from other
> > > sources; either mechanisms for software generally (PyPI,
> > > Openhub), or specific to games (Steam, itch.io ,
> > > gamejolt)
> > >   - [My thoughts: the general sources don't seem a great fit;
> > > it's rare to upload screenshots to these, and even if developers
> > > did, we would have to scrape them from free text. Pulling from game
> > > stores would mean games have to clear a much higher bar of
> > > quality and polish than many of the current entries on the feed.
> > > That is up for discussion, but I like the current amateur-friendly
> > > feel of the feed. If you just want polished games to play, it
> > > wouldn't matter that they're in Python]
>
>
> --
> Radomir Dopieralski
>


Re: [pygame] New pygame.org website

2016-12-17 Thread Daniel Foerster
I just checked the Sphinx documentation, and it looks like sphinx-apidoc 
can do what we'd need in terms of creating files that could be used as 
input to Nikola.


— Daniel


On 12/17/2016 05:22 PM, Radomir Dopieralski wrote:

I think we will want to limit the amount of work necessary, at least at
the start -- that means using the current documentation how it is, with
Sphinx, perhaps with a custom Sphinx theme that makes it consistent
with the rest of the website. Don't fix what is not broken. Let's focus
on the things that really require work, and let's do that first -- I'm
sure there is plenty to do already.

On Sat, 17 Dec 2016 17:09:03 -0600
Daniel Foerster  wrote:


I think the easiest way to go will be to generate markdown or ReST
files with Sphinx or another tool and use them as input to Nikola.
Otherwise we have to include the pygame source in the website
repository, which doesn't seem ideal to me.

— Daniel

On 12/17/2016 04:54 PM, Paul Vincent Craven wrote:

Is it possible to get Nikola to build the Pygame docs, or will that
have to remain Sphinx based?

Paul Vincent Craven

On Sat, Dec 17, 2016 at 4:26 PM, Thomas Kluyver > wrote:

 On 17 December 2016 at 20:40, Alex Z. > wrote:

 More important: I think it would be cool to do a real
 brainstorming about creative ideas together, as everyone has
 an own vision and arguments for how the site should be and
 mail is such a slow medium.
 Maybe we can do a Skype call, Google hangout or whatever
soon so as many people as possible really get involved.
 However we would need a moderator to structure the call and
 protocol the answers. I would suggest Thomas, as he has the
 most experience with pygames history and maintaining its
 resources.


 I should make it clear that I have very little experience with
 maintaining Pygame. I turned up earlier this year to pester
people into making a release. But I'm happy to co-ordinate getting
this work off the ground. :-)

 I have my reservations about a video chat: it's hard to include
 everyone, especially as we're spread across widely spaced time
 zones. Although email is slower, the asynchronous communications
 give everyone a chance to weigh in. But if people agree that a
 video chat would be helpful, I'll try to arrange that.

 So far, I think the proposals for the static information part of
 the site are Nikola (a static site generator oriented around
 blogs) and Sphinx (oriented around docs). Both are written in
 Python. Does anyone want to make the case for any other system?

 Summarising ideas on the game feed part:
 - Maybe it could also be static, so you make a pull request to
 submit a game
 - Others said please don't do that, because it's too difficult
for game developers
   - [I agree with both groups. I wonder if we could make a web
 form which turns the input into a git commit plus pull
request...]
 - Alternatively, we could populate it with data from other
 sources; either mechanisms for software generally (PyPI,
Openhub), or specific to games (Steam, itch.io ,
gamejolt)
   - [My thoughts: the general sources don't seem a great fit;
it's rare to upload screenshots to these, and even if developers
did, we would have to scrape them from free text. Pulling from game
 stores would mean games have to clear a much higher bar of
quality and polish than many of the current entries on the feed.
That is up for discussion, but I like the current amateur-friendly
feel of the feed. If you just want polished games to play, it
wouldn't matter that they're in Python]






Re: [pygame] New pygame.org website

2016-12-17 Thread Charles Cossé
On Sat, Dec 17, 2016 at 4:12 PM, Daniel Foerster 
wrote:

> Using S3/CloudFront is a lot cheaper than the EC2 setup you're imagining
> (and which a Django stack would require).
>
>
I never said to use Amazon at all.  Just use the current server, whatever
it is (unless it's Amazon).



> On 12/17/2016 05:11 PM, Charles Cossé wrote:
>
> Yikes!  who's gonna pay the Amazon bill?
>
> On Sat, Dec 17, 2016 at 4:09 PM, Paul Vincent Craven <
> p...@cravenfamily.com> wrote:
>
>> If most of the site is static, then I think Django would be overkill. The
>> static portion of the site can easily be deployed via Amazon S3/CloudFront
>> and then we'd not have to maintain a server.
>>
>> Paul Vincent Craven
>>
>> On Sat, Dec 17, 2016 at 5:00 PM, Charles Cossé  wrote:
>>
>>>
>>> On Sat, Dec 17, 2016 at 3:26 PM, Thomas Kluyver 
>>> wrote:
>>>

 So far, I think the proposals for the static information part of the
 site are Nikola (a static site generator oriented around blogs) and Sphinx
 (oriented around docs). Both are written in Python. Does anyone want to
 make the case for any other system?


>>> Can Django factor-in there?  I guess it would reside underneathe the
>>> other pkgs ... but might as well run Python through-and-through imho.
>>>
>>>
>>
>
>
> --
>
> Linkedin  | E-Learning
> 
>
>
>
>


-- 

Linkedin  | E-Learning



Re: [pygame] New pygame.org website

2016-12-17 Thread Daniel Foerster
Like you say though, using the Sphinx output straight up will require a 
custom theme. Right there you've sunk the same amount of work into 
Sphinx and you're still using two separate tools. Better to get the docs 
and website in sync from the start, in my opinion.


— Daniel

On 12/17/2016 05:22 PM, Radomir Dopieralski wrote:

I think we will want to limit the amount of work necessary, at least at
the start -- that means using the current documentation how it is, with
Sphinx, perhaps with a custom Sphinx theme that makes it consistent
with the rest of the website. Don't fix what is not broken. Let's focus
on the things that really require work, and let's do that first -- I'm
sure there is plenty to do already.

On Sat, 17 Dec 2016 17:09:03 -0600
Daniel Foerster  wrote:


I think the easiest way to go will be to generate markdown or ReST
files with Sphinx or another tool and use them as input to Nikola.
Otherwise we have to include the pygame source in the website
repository, which doesn't seem ideal to me.

— Daniel

On 12/17/2016 04:54 PM, Paul Vincent Craven wrote:

Is it possible to get Nikola to build the Pygame docs, or will that
have to remain Sphinx based?

Paul Vincent Craven

On Sat, Dec 17, 2016 at 4:26 PM, Thomas Kluyver > wrote:

 On 17 December 2016 at 20:40, Alex Z. > wrote:

 More important: I think it would be cool to do a real
 brainstorming about creative ideas together, as everyone has
 an own vision and arguments for how the site should be and
 mail is such a slow medium.
 Maybe we can do a Skype call, Google hangout or whatever
soon so as many people as possible really get involved.
 However we would need a moderator to structure the call and
 protocol the answers. I would suggest Thomas, as he has the
 most experience with pygames history and maintaining its
 resources.


 I should make it clear that I have very little experience with
 maintaining Pygame. I turned up earlier this year to pester
people into making a release. But I'm happy to co-ordinate getting
this work off the ground. :-)

 I have my reservations about a video chat: it's hard to include
 everyone, especially as we're spread across widely spaced time
 zones. Although email is slower, the asynchronous communications
 give everyone a chance to weigh in. But if people agree that a
 video chat would be helpful, I'll try to arrange that.

 So far, I think the proposals for the static information part of
 the site are Nikola (a static site generator oriented around
 blogs) and Sphinx (oriented around docs). Both are written in
 Python. Does anyone want to make the case for any other system?

 Summarising ideas on the game feed part:
 - Maybe it could also be static, so you make a pull request to
 submit a game
 - Others said please don't do that, because it's too difficult
for game developers
   - [I agree with both groups. I wonder if we could make a web
 form which turns the input into a git commit plus pull
request...]
 - Alternatively, we could populate it with data from other
 sources; either mechanisms for software generally (PyPI,
Openhub), or specific to games (Steam, itch.io ,
gamejolt)
   - [My thoughts: the general sources don't seem a great fit;
it's rare to upload screenshots to these, and even if developers
did, we would have to scrape them from free text. Pulling from game
 stores would mean games have to clear a much higher bar of
quality and polish than many of the current entries on the feed.
That is up for discussion, but I like the current amateur-friendly
feel of the feed. If you just want polished games to play, it
wouldn't matter that they're in Python]






Re: [pygame] New pygame.org website

2016-12-17 Thread Radomir Dopieralski
I think we will want to limit the amount of work necessary, at least at
the start -- that means using the current documentation how it is, with
Sphinx, perhaps with a custom Sphinx theme that makes it consistent
with the rest of the website. Don't fix what is not broken. Let's focus
on the things that really require work, and let's do that first -- I'm
sure there is plenty to do already.

On Sat, 17 Dec 2016 17:09:03 -0600
Daniel Foerster  wrote:

> I think the easiest way to go will be to generate markdown or ReST
> files with Sphinx or another tool and use them as input to Nikola.
> Otherwise we have to include the pygame source in the website
> repository, which doesn't seem ideal to me.
> 
> — Daniel
> 
> On 12/17/2016 04:54 PM, Paul Vincent Craven wrote:
> > Is it possible to get Nikola to build the Pygame docs, or will that 
> > have to remain Sphinx based?
> >
> > Paul Vincent Craven
> >
> > On Sat, Dec 17, 2016 at 4:26 PM, Thomas Kluyver  > > wrote:
> >
> > On 17 December 2016 at 20:40, Alex Z.  > > wrote:
> >
> > More important: I think it would be cool to do a real
> > brainstorming about creative ideas together, as everyone has
> > an own vision and arguments for how the site should be and
> > mail is such a slow medium.
> > Maybe we can do a Skype call, Google hangout or whatever
> > soon so as many people as possible really get involved.
> > However we would need a moderator to structure the call and
> > protocol the answers. I would suggest Thomas, as he has the
> > most experience with pygames history and maintaining its
> > resources.
> >
> >
> > I should make it clear that I have very little experience with
> > maintaining Pygame. I turned up earlier this year to pester
> > people into making a release. But I'm happy to co-ordinate getting
> > this work off the ground. :-)
> >
> > I have my reservations about a video chat: it's hard to include
> > everyone, especially as we're spread across widely spaced time
> > zones. Although email is slower, the asynchronous communications
> > give everyone a chance to weigh in. But if people agree that a
> > video chat would be helpful, I'll try to arrange that.
> >
> > So far, I think the proposals for the static information part of
> > the site are Nikola (a static site generator oriented around
> > blogs) and Sphinx (oriented around docs). Both are written in
> > Python. Does anyone want to make the case for any other system?
> >
> > Summarising ideas on the game feed part:
> > - Maybe it could also be static, so you make a pull request to
> > submit a game
> > - Others said please don't do that, because it's too difficult
> > for game developers
> >   - [I agree with both groups. I wonder if we could make a web
> > form which turns the input into a git commit plus pull
> > request...]
> > - Alternatively, we could populate it with data from other
> > sources; either mechanisms for software generally (PyPI,
> > Openhub), or specific to games (Steam, itch.io ,
> > gamejolt)
> >   - [My thoughts: the general sources don't seem a great fit;
> > it's rare to upload screenshots to these, and even if developers
> > did, we would have to scrape them from free text. Pulling from game
> > stores would mean games have to clear a much higher bar of
> > quality and polish than many of the current entries on the feed.
> > That is up for discussion, but I like the current amateur-friendly
> > feel of the feed. If you just want polished games to play, it
> > wouldn't matter that they're in Python]


-- 
Radomir Dopieralski


Re: [pygame] New pygame.org website

2016-12-17 Thread Daniel Foerster
Using S3/CloudFront is a lot cheaper than the EC2 setup you're imagining 
(and which a Django stack would require).



On 12/17/2016 05:11 PM, Charles Cossé wrote:

Yikes!  who's gonna pay the Amazon bill?

On Sat, Dec 17, 2016 at 4:09 PM, Paul Vincent Craven 
> wrote:


If most of the site is static, then I think Django would be
overkill. The static portion of the site can easily be deployed
via Amazon S3/CloudFront and then we'd not have to maintain a server.

Paul Vincent Craven

On Sat, Dec 17, 2016 at 5:00 PM, Charles Cossé > wrote:


On Sat, Dec 17, 2016 at 3:26 PM, Thomas Kluyver
> wrote:


So far, I think the proposals for the static information
part of the site are Nikola (a static site generator
oriented around blogs) and Sphinx (oriented around docs).
Both are written in Python. Does anyone want to make the
case for any other system?


Can Django factor-in there?  I guess it would reside
underneathe the other pkgs ... but might as well run Python
through-and-through imho.





--

Linkedin  | E-Learning 








Re: [pygame] New pygame.org website

2016-12-17 Thread Charles Cossé
Amazon would be overkill, imho

On Sat, Dec 17, 2016 at 4:11 PM, Charles Cossé  wrote:

> Yikes!  who's gonna pay the Amazon bill?
>
> On Sat, Dec 17, 2016 at 4:09 PM, Paul Vincent Craven <
> p...@cravenfamily.com> wrote:
>
>> If most of the site is static, then I think Django would be overkill. The
>> static portion of the site can easily be deployed via Amazon S3/CloudFront
>> and then we'd not have to maintain a server.
>>
>> Paul Vincent Craven
>>
>> On Sat, Dec 17, 2016 at 5:00 PM, Charles Cossé  wrote:
>>
>>>
>>> On Sat, Dec 17, 2016 at 3:26 PM, Thomas Kluyver 
>>> wrote:
>>>

 So far, I think the proposals for the static information part of the
 site are Nikola (a static site generator oriented around blogs) and Sphinx
 (oriented around docs). Both are written in Python. Does anyone want to
 make the case for any other system?


>>> Can Django factor-in there?  I guess it would reside underneathe the
>>> other pkgs ... but might as well run Python through-and-through imho.
>>>
>>>
>>
>
>
> --
>
> Linkedin  | E-Learning
> 
>
>
>


-- 

Linkedin  | E-Learning



Re: [pygame] New pygame.org website

2016-12-17 Thread Charles Cossé
Yikes!  who's gonna pay the Amazon bill?

On Sat, Dec 17, 2016 at 4:09 PM, Paul Vincent Craven 
wrote:

> If most of the site is static, then I think Django would be overkill. The
> static portion of the site can easily be deployed via Amazon S3/CloudFront
> and then we'd not have to maintain a server.
>
> Paul Vincent Craven
>
> On Sat, Dec 17, 2016 at 5:00 PM, Charles Cossé  wrote:
>
>>
>> On Sat, Dec 17, 2016 at 3:26 PM, Thomas Kluyver  wrote:
>>
>>>
>>> So far, I think the proposals for the static information part of the
>>> site are Nikola (a static site generator oriented around blogs) and Sphinx
>>> (oriented around docs). Both are written in Python. Does anyone want to
>>> make the case for any other system?
>>>
>>>
>> Can Django factor-in there?  I guess it would reside underneathe the
>> other pkgs ... but might as well run Python through-and-through imho.
>>
>>
>


-- 

Linkedin  | E-Learning



Re: [pygame] New pygame.org website

2016-12-17 Thread Daniel Foerster
I think the easiest way to go will be to generate markdown or ReST files 
with Sphinx or another tool and use them as input to Nikola. Otherwise 
we have to include the pygame source in the website repository, which 
doesn't seem ideal to me.


— Daniel

On 12/17/2016 04:54 PM, Paul Vincent Craven wrote:
Is it possible to get Nikola to build the Pygame docs, or will that 
have to remain Sphinx based?


Paul Vincent Craven

On Sat, Dec 17, 2016 at 4:26 PM, Thomas Kluyver > wrote:


On 17 December 2016 at 20:40, Alex Z. > wrote:

More important: I think it would be cool to do a real
brainstorming about creative ideas together, as everyone has
an own vision and arguments for how the site should be and
mail is such a slow medium.
Maybe we can do a Skype call, Google hangout or whatever soon
so as many people as possible really get involved.
However we would need a moderator to structure the call and
protocol the answers. I would suggest Thomas, as he has the
most experience with pygames history and maintaining its
resources.


I should make it clear that I have very little experience with
maintaining Pygame. I turned up earlier this year to pester people
into making a release. But I'm happy to co-ordinate getting this
work off the ground. :-)

I have my reservations about a video chat: it's hard to include
everyone, especially as we're spread across widely spaced time
zones. Although email is slower, the asynchronous communications
give everyone a chance to weigh in. But if people agree that a
video chat would be helpful, I'll try to arrange that.

So far, I think the proposals for the static information part of
the site are Nikola (a static site generator oriented around
blogs) and Sphinx (oriented around docs). Both are written in
Python. Does anyone want to make the case for any other system?

Summarising ideas on the game feed part:
- Maybe it could also be static, so you make a pull request to
submit a game
- Others said please don't do that, because it's too difficult for
game developers
  - [I agree with both groups. I wonder if we could make a web
form which turns the input into a git commit plus pull request...]
- Alternatively, we could populate it with data from other
sources; either mechanisms for software generally (PyPI, Openhub),
or specific to games (Steam, itch.io , gamejolt)
  - [My thoughts: the general sources don't seem a great fit; it's
rare to upload screenshots to these, and even if developers did,
we would have to scrape them from free text. Pulling from game
stores would mean games have to clear a much higher bar of quality
and polish than many of the current entries on the feed. That is
up for discussion, but I like the current amateur-friendly feel of
the feed. If you just want polished games to play, it wouldn't
matter that they're in Python]

Thomas






Re: [pygame] New pygame.org website

2016-12-17 Thread Paul Vincent Craven
If most of the site is static, then I think Django would be overkill. The
static portion of the site can easily be deployed via Amazon S3/CloudFront
and then we'd not have to maintain a server.

Paul Vincent Craven

On Sat, Dec 17, 2016 at 5:00 PM, Charles Cossé  wrote:

>
> On Sat, Dec 17, 2016 at 3:26 PM, Thomas Kluyver  wrote:
>
>>
>> So far, I think the proposals for the static information part of the site
>> are Nikola (a static site generator oriented around blogs) and Sphinx
>> (oriented around docs). Both are written in Python. Does anyone want to
>> make the case for any other system?
>>
>>
> Can Django factor-in there?  I guess it would reside underneathe the other
> pkgs ... but might as well run Python through-and-through imho.
>
>


Re: [pygame] New pygame.org website

2016-12-17 Thread Charles Cossé
On Sat, Dec 17, 2016 at 3:26 PM, Thomas Kluyver  wrote:

>
> So far, I think the proposals for the static information part of the site
> are Nikola (a static site generator oriented around blogs) and Sphinx
> (oriented around docs). Both are written in Python. Does anyone want to
> make the case for any other system?
>
>
Can Django factor-in there?  I guess it would reside underneathe the other
pkgs ... but might as well run Python through-and-through imho.


Re: [pygame] New pygame.org website

2016-12-17 Thread Paul Vincent Craven
Is it possible to get Nikola to build the Pygame docs, or will that have to
remain Sphinx based?

Paul Vincent Craven

On Sat, Dec 17, 2016 at 4:26 PM, Thomas Kluyver  wrote:

> On 17 December 2016 at 20:40, Alex Z.  wrote:
>
>> More important: I think it would be cool to do a real brainstorming about
>> creative ideas together, as everyone has an own vision and arguments for
>> how the site should be and mail is such a slow medium.
>> Maybe we can do a Skype call, Google hangout or whatever soon so as many
>> people as possible really get involved.
>> However we would need a moderator to structure the call and protocol the
>> answers. I would suggest Thomas, as he has the most experience with pygames
>> history and maintaining its resources.
>>
>
> I should make it clear that I have very little experience with maintaining
> Pygame. I turned up earlier this year to pester people into making a
> release. But I'm happy to co-ordinate getting this work off the ground. :-)
>
> I have my reservations about a video chat: it's hard to include everyone,
> especially as we're spread across widely spaced time zones. Although email
> is slower, the asynchronous communications give everyone a chance to weigh
> in. But if people agree that a video chat would be helpful, I'll try to
> arrange that.
>
> So far, I think the proposals for the static information part of the site
> are Nikola (a static site generator oriented around blogs) and Sphinx
> (oriented around docs). Both are written in Python. Does anyone want to
> make the case for any other system?
>
> Summarising ideas on the game feed part:
> - Maybe it could also be static, so you make a pull request to submit a
> game
> - Others said please don't do that, because it's too difficult for game
> developers
>   - [I agree with both groups. I wonder if we could make a web form which
> turns the input into a git commit plus pull request...]
> - Alternatively, we could populate it with data from other sources; either
> mechanisms for software generally (PyPI, Openhub), or specific to games
> (Steam, itch.io, gamejolt)
>   - [My thoughts: the general sources don't seem a great fit; it's rare to
> upload screenshots to these, and even if developers did, we would have to
> scrape them from free text. Pulling from game stores would mean games have
> to clear a much higher bar of quality and polish than many of the current
> entries on the feed. That is up for discussion, but I like the current
> amateur-friendly feel of the feed. If you just want polished games to play,
> it wouldn't matter that they're in Python]
>
> Thomas
>


Re: [pygame] New pygame.org website

2016-12-17 Thread Thomas Kluyver
On 17 December 2016 at 20:40, Alex Z.  wrote:

> More important: I think it would be cool to do a real brainstorming about
> creative ideas together, as everyone has an own vision and arguments for
> how the site should be and mail is such a slow medium.
> Maybe we can do a Skype call, Google hangout or whatever soon so as many
> people as possible really get involved.
> However we would need a moderator to structure the call and protocol the
> answers. I would suggest Thomas, as he has the most experience with pygames
> history and maintaining its resources.
>

I should make it clear that I have very little experience with maintaining
Pygame. I turned up earlier this year to pester people into making a
release. But I'm happy to co-ordinate getting this work off the ground. :-)

I have my reservations about a video chat: it's hard to include everyone,
especially as we're spread across widely spaced time zones. Although email
is slower, the asynchronous communications give everyone a chance to weigh
in. But if people agree that a video chat would be helpful, I'll try to
arrange that.

So far, I think the proposals for the static information part of the site
are Nikola (a static site generator oriented around blogs) and Sphinx
(oriented around docs). Both are written in Python. Does anyone want to
make the case for any other system?

Summarising ideas on the game feed part:
- Maybe it could also be static, so you make a pull request to submit a game
- Others said please don't do that, because it's too difficult for game
developers
  - [I agree with both groups. I wonder if we could make a web form which
turns the input into a git commit plus pull request...]
- Alternatively, we could populate it with data from other sources; either
mechanisms for software generally (PyPI, Openhub), or specific to games
(Steam, itch.io, gamejolt)
  - [My thoughts: the general sources don't seem a great fit; it's rare to
upload screenshots to these, and even if developers did, we would have to
scrape them from free text. Pulling from game stores would mean games have
to clear a much higher bar of quality and polish than many of the current
entries on the feed. That is up for discussion, but I like the current
amateur-friendly feel of the feed. If you just want polished games to play,
it wouldn't matter that they're in Python]

Thomas


Re: [pygame] New pygame.org website

2016-12-17 Thread Alex Z.
Wout B and I started to work on a Python gaming related site, but we didn't
do that much until now, so I can share the designs we got, although it
isn't much.

More important: I think it would be cool to do a real brainstorming about
creative ideas together, as everyone has an own vision and arguments for
how the site should be and mail is such a slow medium.
Maybe we can do a Skype call, Google hangout or whatever soon so as many
people as possible really get involved.
However we would need a moderator to structure the call and protocol the
answers. I would suggest Thomas, as he has the most experience with pygames
history and maintaining its resources.


Re: [pygame] New pygame.org website

2016-12-17 Thread DiliupG
The games list would be what would encourage new people to dive into game
development and other exiting things to do with Python so I think we should
put that on the site but as Christopher Knight says make it as simple as
possible for someone to upload game files. Not everyone uses any kind of
repository.

On Sat, Dec 17, 2016 at 1:30 PM, Tom Rothamel  wrote:

> Can I suggest foregoing development of the games list for the time being,
> and just linking to the appropriate tags on steam, itch.io, gamejolt,
> etc? A games list is a bit of effort to develop, and a lot more to keep
> going and curated against spammers. It's an ongoing burden that will likely
> wear out those that take it on, and divert effort away from the rest of the
> website and the project.
>
>
> On Sat, Dec 17, 2016 at 2:06 AM Christopher Night 
> wrote:
>
>> 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 
>> 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 +
>> Thomas Kluyver  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 

Re: [pygame] New pygame.org website

2016-12-17 Thread Tom Rothamel
Can I suggest foregoing development of the games list for the time being,
and just linking to the appropriate tags on steam, itch.io, gamejolt, etc?
A games list is a bit of effort to develop, and a lot more to keep going
and curated against spammers. It's an ongoing burden that will likely wear
out those that take it on, and divert effort away from the rest of the
website and the project.


On Sat, Dec 17, 2016 at 2:06 AM Christopher Night 
wrote:

> 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 
> 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 +
> Thomas Kluyver  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. 

Re: [pygame] New pygame.org website

2016-12-16 Thread Daniel Foerster
> A downside is all pages built with a particular theme share the same
> layout. For example, in the Pygame docs the same Jinja2 templates generate
> the index page, module reference pages, and tutorial pages. So if you want
> a sidebar on one page, you get it on all pages. And I imagine to get around
> this needs another level of complexity, such as multiple document trees
> with each tree using a different theme.


Easiest way to get around this is to include the sidebar in the input page
and just style it correctly using the template.


Re: [pygame] New pygame.org website

2016-12-16 Thread Lenard Lindstrom

Hello,

My experience is in setting up the Pygame documentation generator under 
Sphinx. So all the hacks to get a unsphinx-like banner with links to all 
the module pages was my work.


On 16-12-16 09:59 AM, Thomas Kluyver wrote:
On 16 December 2016 at 10:12, Radomir Dopieralski > wrote:


As for the tools, I wonder if we could just use Sphinx like all the
PyGame documentation does, and not get extra tools involved.


I've made websites with Sphinx before (ipython.org 
), and my experience was that it's not a great 
tool for that task - it's designed around docs, and you have to do a 
fair bit to suppress docs-oriented features and checks that don't make 
sense for a website, such as having all the pages in a strict order 
for conversion to PDF.


My experience is that Sphinx organizes document source files in a tree 
structure, with a root document linking to child documents which can 
have children in turn. When adding a new document, the main concern is 
that it is added into the tree somewhere. Sphinx supports wild card 
patterns and directory recursion to simplify this.


A downside is all pages built with a particular theme share the same 
layout. For example, in the Pygame docs the same Jinja2 templates 
generate the index page, module reference pages, and tutorial pages. So 
if you want a sidebar on one page, you get it on all pages. And I 
imagine to get around this needs another level of complexity, such as 
multiple document trees with each tree using a different theme.




Re: [pygame] New pygame.org website

2016-12-16 Thread Radomir Dopieralski
Another idea that came to my mind just now for the game list, is to use
one of the many existing software catalogs, and pull the data from
there. We could, for example, use PyPi, and thus encourage people to
publish their projects there. Or we could use something like ohloh (I
think it's called openhub.net now), which has some nice user interface
and stats. I'm sure there are much more such services.

On Fri, 16 Dec 2016 17:59:02 +
Thomas Kluyver  wrote:

> On 16 December 2016 at 10:12, Radomir Dopieralski
>  wrote:
> 
> > As for the tools, I wonder if we could just use Sphinx like all the
> > PyGame documentation does, and not get extra tools involved.
> >  
> 
> I've made websites with Sphinx before (ipython.org), and my
> experience was that it's not a great tool for that task - it's
> designed around docs, and you have to do a fair bit to suppress
> docs-oriented features and checks that don't make sense for a
> website, such as having all the pages in a strict order for
> conversion to PDF.
> 
> That said, Nikola (and, I think, most static site generators) are
> really designed around a blog, which isn't exactly what we want
> either.
> 
> 
> > 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.
> >  
> 
> I did wonder about that. It's not ideal, because pull requests have
> to be merged, but it is an attractive option for simplicity. Maybe if
> it was a separate repo, we could give out push access very freely so
> that there were many people who could merge pull requests.
> 
> 
> > 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?
> >  
> 
> I would move it into the version-controlled static site. I think
> wikis were popular at one point a few years back, but they don't
> actually work that well. Part of the problem is that people can be
> reluctant to edit a wiki in case they're wrong. Making changes
> through pull requests makes those people more willing to have a go,
> because they know someone else will check it. And it provides some
> protection against bad edits.
> 
> If we decide we really need a wiki, I'd probably go for the Github
> wiki, but let's try with just the version controlled site first.
> 
> Thomas
> 
> PS Does anyone know who owns the pygame organisation on Github? It's
> claimed but not in use.



-- 
Radomir Dopieralski

-- 
Radomir Dopieralski


Re: [pygame] New pygame.org website

2016-12-16 Thread Thomas Kluyver
On 16 December 2016 at 10:12, Radomir Dopieralski 
wrote:

> As for the tools, I wonder if we could just use Sphinx like all the
> PyGame documentation does, and not get extra tools involved.
>

I've made websites with Sphinx before (ipython.org), and my experience was
that it's not a great tool for that task - it's designed around docs, and
you have to do a fair bit to suppress docs-oriented features and checks
that don't make sense for a website, such as having all the pages in a
strict order for conversion to PDF.

That said, Nikola (and, I think, most static site generators) are really
designed around a blog, which isn't exactly what we want either.


> 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.
>

I did wonder about that. It's not ideal, because pull requests have to be
merged, but it is an attractive option for simplicity. Maybe if it was a
separate repo, we could give out push access very freely so that there were
many people who could merge pull requests.


> 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?
>

I would move it into the version-controlled static site. I think wikis were
popular at one point a few years back, but they don't actually work that
well. Part of the problem is that people can be reluctant to edit a wiki in
case they're wrong. Making changes through pull requests makes those people
more willing to have a go, because they know someone else will check it.
And it provides some protection against bad edits.

If we decide we really need a wiki, I'd probably go for the Github wiki,
but let's try with just the version controlled site first.

Thomas

PS Does anyone know who owns the pygame organisation on Github? It's
claimed but not in use.


Re: [pygame] New pygame.org website

2016-12-16 Thread Enrico Kochon
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 +
> Thomas Kluyver  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
>> 

Re: [pygame] New pygame.org website

2016-12-16 Thread 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 +
Thomas Kluyver  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 

Re: [pygame] New pygame.org website

2016-12-15 Thread Ian Mallett
On Thu, Dec 15, 2016 at 1:23 PM, Thomas Kluyver  wrote:

> If you're interested in helping to build this, or you have ideas about how
> best to do it, please reply to this email!
>
​I would be interested in helping. My knowledge of web development is
"basic" (and that's being generous). I do know the basics of HTML, PHP, and
Javascript though.

I support Python-based tools, Markdown, and possibly making the site on
Github.


Re: [pygame] New pygame.org website

2016-12-15 Thread Paul Vincent Craven
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 
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"  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 

Re: [pygame] New pygame.org website

2016-12-15 Thread Daniel Foerster
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"  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!
>
>
>
>