Wanna another? (early 2016 edition)

[Eremiell]

After some further discussion on IRC, we're going to allow copyleft licenses. Updated rules ahead. As we require participants to have some kind of license, I also prepared an introductory text for those without clue. If you have a clue, that text isn't really meant for you, but feel free to read it anyway or skip it at your discretion. It's not part of official rules and I ask everyone to not start flames about licenses. If you wanna have civilized chat about it, come to #sfmlgamejam @ BoxBox IRC.


Time Frame:
1. Participants are given 16 days (Saturday midnight UTC to Monday midnight UTC) to work on their game.
2. The theme of the jam is released 24 hours before the jam officially starts, and everyone is encouraged to use this time for brainstorming ideas.
3. Additional 48 hours are given to participants for packaging the game. No major development should be done in this time.

Submission Info:
4. A link to source is required when submitting. Source and any assets created for the game has to be release into Public Domain or under permissive or copyleft license unless they're a derivative work of someone else's work, which can't be released so. Participants are encouraged to use permissive license for maximal reusability of the work. Recommendations for participants not fond of any given license are given on the bottom of the rules.
5. A link to a playable version of the game for either Windows, Mac, or Linux is required when submitting. This must include the executable and all assets/extras needed to run the game.
6. Games with NSFW or shocking content must be marked as such.
7. You are allowed to submit as early as you want, but there is no reward for doing so.

Rules:
8. You can work on a team of any size, or by yourself. Team size and members must be stated when submitting.
9. You only have 16 days to create any original code and audio/graphic assets needed for your project. Any resources are allowed as long as you have rights to use them, but you shouldn't work on creating or obtaining any resources meant specifically for the jam between theme announcement and jam beginning.
10. Game should be based on the theme, but how the theme is interpreted is up to you!
11. Any programming language may be used, as long as SFML (or one of its bindings) is used.
12. External libraries are allowed, but not SFML's competitors, such as GLFW, SDL, Allegro, etc. The use of OpenGL is allowed, however.
13. You have to give credit to original authors of any resources you use, that are not your own, even when the license doesn't enforce that. (Mostly so it's clear what is and what isn't your work.)
14. Porting to other OS's after the 16 days mark, as well as fixing small bugs in your game and any issues with your packaging is allowed and encouraged!
15. You're allowed to continue work on your game, but you have to keep the version made during the jam (with exceptions per rule 14) for voting.

Themes:
16. Theme voting takes place before theme announcement. Each participant is allowed to vote.
17. Initially participants are allowed to submit theme ideas.
18. Theme ideas must not be offensive, vague, too similar to theme of any previous SFML Game Jam or recent iterations of any major game jam and must make sense.
19. Themes will be hand approved by SFML Game Jam organizers. Organizers can also slightly rephrase the idea. Approval or disapproval of any idea and any rephrasing is final.
20. The approved themes will be voted on in several rounds.
21. Each round each participant has limited amount of votes decided by organizers based on amount of approved theme ideas. The number of votes as well as the number of rounds will be known to participant at the beginning of the first voting round. Number of votes will be the same in all rounds including the final round.
22. Votes can be used to cast positive or negative points on ideas in the given round.
23. Theme ideas with best scores from each round will progress to the final round. Winner of the final round will be announced as the jam theme.

Voting:
24. Once delivery phase is over, voting takes place. Everyone with an account of the jam site has right to vote (even non-participants).
25. Voting takes place in several categories, that will be known to voters on the beginning of the voting phase.
26. Participants can decide to not take place in voting for some categories for any reason.
27. Winner in each category as well as overall winner will be announced once the voting is over.


License Recommendations:
Those are just recommendations meant primarily for those that don't have any idea how to license the game. As code/assets without any stated license doesn't provide any rights and therefore can't be reused in any way, but are also (wrongly) seen by many as in Public Domain, it's important to always state your license and therefore your intentions with your work. All participants are free to use any other licenses as long as they're either permissive or copyleft.

This part is completely informal and meant just as help for those completely lost in the world of licenses. It's not meant to indicate some license or group of licenses is better than another. Things might be slightly simplified here for the sake of clarity, so read further sources and primarily the license text itself if you want to be sure. This should not be interpreted as a legal advice of any kind.

Once you pick your license or licenses (you can license different parts of your work by different licenses and it's usually good idea to split at least by code and assets as they behave quite differently), just copy it's full text, edit any parts like <author> or <year> and put in into file called LICENSE in your repository/work folder. You can also mention the license in your README or in header comment of individual source files, but that shouldn't be needed. You should always redistribute your license with sources and possibly even with binaries (that depends on license, but it doesn't hurt you to do so).

Generally speaking, you have three options. Let's dig into each a bit.

1. Public Domain
This option is for you, if you don't care tiniest bit what anyone does with your work. You want to give it to everyone, for free, to be used however they like. They can reuse any parts or the whole thing and don't have to bother you about it. You're basically giving it away, for real.

Unless you want to compose your own Public Domain statement, you've got two main options in this category and the nice bit is, you can license your code and your assets using one license, as you just waive all rights and there's not much to care about further.
Unlicense tl;dr;Legal
CC0 tl;dr;Legal

It shouldn't make much difference which one you choose, the second one is probably slightly more popular, but that's about it.

2. Permissive license

If you don't want to give the thing away fully, but also want to let anyone use it for anything they want without much concern (that is including commercial use and about anything), you should consider a permissive license. Details might slightly differ, but mostly you require to get your copyright notice and that's it. No one has to bother you to reuse the work, yet you still own it.

Some good choices for code here are:
zlib tl;dr;Legal
MIT tl;dr;Legal
BSD tl;dr;Legal
ISC tl;dr;Legal
Apache tl;dr;Legal
Artistic tl;dr;Legal

The first four are quite similar, short, permissive, the other two are slightly longer. What they allow and disallow also slightly differs, but the main idea is similar. The first one is used by SFML itself.

And you'll want to license the assets with a different one:
MirOS tl;dr;Legal
CC-BY tl;dr;Legal

Here, the first one derives from BSD license and gives roughly the same care to your assets, while the second one is probably the most popular permissive asset license.

3. Copyleft

Now you not just wanna give, but you wanna everyone else to give back. That sounds wonderful, but also poses some limitations, as generally any derived work must reuse the same license and that's not always practical. Still, you can do this. There's also slight difference between strong and weak copyleft, where the first one demands even other components to adapt, while the second one only cares about itself, so it can be used together with things under other licenses.

Weak copyleft for your code:
Mozilla tl;dr;Legal
LGPL tl;dr;Legal

Strong copyleft for your code:
GPL tl;dr;Legal

Weak copyleft for your assets:
Against DRM
CC-BY-SA tl;dr;Legal
FAL

I don't know about any way to strongly copyleft assets, as they mostly behave like solitary units.

If you're not sure you want to copyleft your code, you might consider one of the first two approaches as in that way, your work will become much more useful.

Some further reading to help you decide:

FreedomDefined
OSI
FSF
ChooseALicense

If you still don't know, probably just pick one of the three approaches and use the first one on list for code and for assets or ask around, but expect quite mixed feelings about any of them.


Regarding the license recommendation, I'm pretty sure some people would disapprove about something, as licensing is one of never ending hot topics around the software community. Please keep the flame down. It's meant for people totally lost in licensing so they have some starting point. If you have some serious practical objections (like I seriously misinterpreted something, which could happen as I'm no lawyer), approach me preferably on IRC or in some private manner to not induce flamewars. I'm prepared to fix any real issues with the text. Also note that the text is informal and not part of official rules. It's meant to help people, not to tell you which license to use, if you have any preferences.

[Nexus]

16 days is an option, but it's not a game jam anymore. The whole feel of getting something cool done in short amounts of time is lost, and I can imagine motivation with it. It may be worth a try for the sake of people who have no time at all otherwise, but you have to consider that some people who would join short jams may not do so in longer jams. Also, the time available may vary massively between participants, so it's again more difficult to compare the results.

The "24h before" and "48h+ after" are questionable in my opinion, especially when the time frame is already astronomically long. But even otherwise, why can't brainstorming and bugfixing not be part of the project, and hence the deadline? In reality, you don't get extra time for anything you do either, and it's a good skill to incorporate planning as well as refining/bugfixing in the time schedule. Bugfixing especially would even increase the quality in my opinion -- when participants know that their stuff has to work by the end of the deadline, they'll focus more on quality and less on quantity and the motto "I can still fix things later".

Regarding "this jam is organized by SFML community and the community wants to get something back" -- well, the community gets the game. The main workload and talent lies on the developer's side. The community actually does nothing besides choosing the theme. I'm not saying we should close-source the contributions, but this argument is not the best one. I'd rather see the advantage of open-source in that it helps get insights into game development and SFML, with different people's takes on it. But we should really not dictate what license people have to choose -- its their code and their intellectual property. I would also omit any recommendations, as they're subjective, make the ruleset unnecessarily longer, and lists of licenses can easily be found on other sites (rather add a link to a neutral overview). And besides, as good as "open source" and its pink-glasses ideology sounds, there's a small chance that it may prevent people from integrating "genius" mechanisms they don't like to publish. But it's an effective way of checking whether rules were followed and code was self-written.

Why do organizers hand-approve and rephrase ideas? That essentially makes them the decisive force, not the community. I agree that such intervention would be a good thing when the topic is inappropriate, for example when it's too broad (like "puzzle" one time). But why rephrase? Furthermore, it's not 100% clear at what stage this happens -- it seems to be before the voting even stars. But then, a lot of interventions would be required, because several topics are not ideal to base a jam on.

Why are game voting categories only known at the beginning of the game voting phase? (Name that differently, to not confuse it with theme voting). If the developer is left in the dark regarding what matters in the end, he can't optimize his game accordingly. For example, if "closeness to the theme" is not one category, the whole point of adhering to the theme is defeated.

The number of rules is too high. This is becoming a bureaucratic mess rather than something simple, and reading walls of text that say nothing meaningful puts people off. Why do we need to mention obvious things like "you have to credit other's work", and that multiple times? Why can't we replace convoluted anti-concise paragraphs like

Source and any assets created for the game has to be release into Public Domain or under permissive or copyleft license unless they're a derivative work of someone else's work, which can't be released so. Participants are encouraged to use permissive license for maximal reusability of the work. Recommendations for participants not fond of any given license are given on the bottom of the rules.

and all the other related ones with

Participants can choose the license of their code and assets freely, but must follow licenses of external work (libraries, assets) used in the game.

Some rules just add to the verbosity without carrying useful information i.e. constraints, such as

7. You are allowed to submit as early as you want, but there is no reward for doing so.
10. Game should be based on the theme, but how the theme is interpreted is up to you!

Others appear to be entirely obvious with the barest minimum of common sense, but have a hidden important constraint:

Theme voting takes place before theme announcement. Each participant is allowed to vote.

People who do not participate are not allowed to vote then? Does the delivery make participants, or anybody who just begins? How to know in advance?

Others are duplicate and can easily be rephrased in fewer points, e.g. 1-9 (time) or 9-12-13 (use of external work).

[Eremiell]

Thanks for input! It's really appreciated.

To address you questions in order:

16 days is an option, but it's not a game jam anymore. The whole feel of getting something cool done in short amounts of time is lost, and I can imagine motivation with it. It may be worth a try for the sake of people who have no time at all otherwise, but you have to consider that some people who would join short jams may not do so in longer jams. Also, the time available may vary massively between participants, so it's again more difficult to compare the results.

There are jams a month long and probably even longer. I have myself named the very same concerns (lack of motivation to do such a long jam being on top), but people asked for such a long time frame. Several people called for it and no one besides me spoken against it, so I backed up on that one and went with the majority.

The "24h before" and "48h+ after" are questionable in my opinion, especially when the time frame is already astronomically long. But even otherwise, why can't brainstorming and bugfixing not be part of the project, and hence the deadline? In reality, you don't get extra time for anything you do either, and it's a good skill to incorporate planning as well as refining/bugfixing in the time schedule. Bugfixing especially would even increase the quality in my opinion -- when participants know that their stuff has to work by the end of the deadline, they'll focus more on quality and less on quantity and the motto "I can still fix things later".

My point of view on this one is, that with such long time frame, it doesn't really make much difference, but I have no strong opinions about it. I proposed it this way, because people were asking for more time and it didn't make any difference for me to allow some more hours for this. Some extra time for both were given previously, so I mostly just scaled that time with the jam itself.

Regarding "this jam is organized by SFML community and the community wants to get something back" -- well, the community gets the game. The main workload and talent lies on the developer's side. The community actually does nothing besides choosing the theme. I'm not saying we should close-source the contributions, but this argument is not the best one. I'd rather see the advantage of open-source in that it helps get insights into game development and SFML, with different people's takes on it. But we should really not dictate what license people have to choose -- its their code and their intellectual property. I would also omit any recommendations, as they're subjective, make the ruleset unnecessarily longer, and lists of licenses can easily be found on other sites (rather add a link to a neutral overview). And besides, as good as "open source" and its pink-glasses ideology sounds, there's a small chance that it may prevent people from integrating "genius" mechanisms they don't like to publish. But it's an effective way of checking whether rules were followed and code was self-written.

There are many reasons why we prefer open source and maybe I haven't pick the strongest ones. My main concerns in this were clarity (everyone can see for themselves) and reusability, for we are often striving for good examples for lot of stuff. The license recommendation weren't meant as part of the rules and I was in fact looking for way to separate them even more. My main concert was some people might have utterly no idea about the whole licensing thing and I wanted to provide some pointers. If people feel the recommendations are really out of place, I can of course completely drop them, but I don't really think any other overview is any more neutral (not implying mine is more neutral than others, but rather that I don't really think any at all can be neutral by nature). I can reduce it to link to fe. ChooseALicense, which is a site provided by GitHub, but its list of licenses is in fact smaller than what I provided and they don't really try to categorize them much or to provide serious alternatives for assets. But I'm open to completely drop this part or bend or reduce it in any way seem fit. I recognize it's a bit controversial and I tried to stay as neutral as possible, just encountered several clear cases of complete misunderstanding in the IRC lately and wanted to provide some elementary help. Maybe I failed at that, hard to judge by myself.

Why do organizers hand-approve and rephrase ideas? That essentially makes them the decisive force, not the community. I agree that such intervention would be a good thing when the topic is inappropriate, for example when it's too broad (like "puzzle" one time). But why rephrase? Furthermore, it's not 100% clear at what stage this happens -- it seems to be before the voting even stars. But then, a lot of interventions would be required, because several topics are not ideal to base a jam on.

This part comes directly from implementation and isn't my invention. From my point of view, any good, non-duplicate ideas should be let through and rephrasing should mostly be used only for fixing obvious grammar errors or similar troubles, possibly replacing a vulgarity with some equivalent meaning in otherwise good ideas. What were the original intentions would know only zsbzsb.

Why are game voting categories only known at the beginning of the game voting phase? (Name that differently, to not confuse it with theme voting). If the developer is left in the dark regarding what matters in the end, he can't optimize his game accordingly. For example, if "closeness to the theme" is not one category, the whole point of adhering to the theme is defeated.

I worded this part this way, because even I have no idea, how far this is in implementation and what are zsbzsb's intentions with it. My idea about it is pretty much copy-paste what LD got, but we can discuss the categories. I believe zsbzsb should be able to add or remove categories pretty much on go, but last time we were talking about his feature, it was something yet to be implemented.

The number of rules is too high. This is becoming a bureaucratic mess rather than something simple, and reading walls of text that say nothing meaningful puts people off. Why do we need to mention obvious things like "you have to credit other's work", and that multiple times? Why can't we replace convoluted anti-concise paragraphs like...

I was trying to open some discussion on the topic and probably find what people would like. As there wasn't exactly abundance of response, I just took all the ideas I mentioned before and tried to sum them up. Even then, I once again asked for input and only reaction I got to this point was "allow copyleft", so I did. I'm still open to draft the rules further and possibly got rid of any or all of them. But we should hurry a bit on that if we wanna do this before next LD.

7. You are allowed to submit as early as you want, but there is no reward for doing so.
10. Game should be based on the theme, but how the theme is interpreted is up to you!

These were minus one word copied from last time rules. I had no reason to drop them, but I acknowledge, they don't add much useful information.

Theme voting takes place before theme announcement. Each participant is allowed to vote.

In my view, participant is anyone with intention to do the jam. As I reasoned several times before, people may try and fail and that just happens. But we still shouldn't support people to just vote and not even try, despite we know we can't do much against such cases. Still we don't want to actively allow that as such behavior is to be frowned upon if nothing else.

I'm up to try to build in your input and any other input that might come. Tomorrow after I wake up that is. Wouldn't end up well right now.

[Nexus]

Several people called for it and no one besides me spoken against it

Yes, I think it's worth a try, it's just a different experience. Would be cool if more people got to participate when they now have time.

My point of view on this one is, that with such long time frame, it doesn't really make much difference

I agree, I meant it more generally (in case we have shorter jams in the future).

The license recommendation weren't meant as part of the rules and I was in fact looking for way to separate them even more.

Maybe something like "participants can choose the license freely" and a link to potential options (on a different page) is a good compromise.

then, I once again asked for input and only reaction I got to this point was "allow copyleft", so I did. I'm still open to draft the rules further and possibly got rid of any or all of them. But we should hurry a bit on that if we wanna do this before next LD.

Yes, unfortunately I haven't had a lot of time recently and so only saw it now. If I can help simplify some rules, I'd gladly do so (but I don't want to just change everything, as you've had a lot of effort drafting the ruleset).

These were minus one word copied from last time rules. I had no reason to drop them, but I acknowledge, they don't add much useful information.

Yes, my main idea is to keep the rules short and to the point, so that people actually read and remember them and can quickly look up what they need. And I think omitting redundant and information-less ones helps in this regard.

I'm up to try to build in your input and any other input that might come. Tomorrow after I wake up that is. Wouldn't end up well right now.

[zsbzsb]

Why do organizers hand-approve and rephrase ideas? That essentially makes them the decisive force, not the community. I agree that such intervention would be a good thing when the topic is inappropriate, for example when it's too broad (like "puzzle" one time). But why rephrase? Furthermore, it's not 100% clear at what stage this happens -- it seems to be before the voting even stars. But then, a lot of interventions would be required, because several topics are not ideal to base a jam on.

This part comes directly from implementation and isn't my invention. From my point of view, any good, non-duplicate ideas should be let through and rephrasing should mostly be used only for fixing obvious grammar errors or similar troubles, possibly replacing a vulgarity with some equivalent meaning in otherwise good ideas. What were the original intentions would know only zsbzsb.

No, organizers are not decisive force at all. All that is done if a theme is appropriate and not generic like 'puzzle' (yes Nexus I know how much you disliked that jam ) is that the organizer can click on it [approve/disapprove] and it will be voted on by the community. Now the ability is there for the person with permission to edit a theme suggestion to whatever they want (if theme suggestions are still open the user will see those changes), but it isn't used that way (same way a mod has permission to edit posts on a forum, but they don't). It is there to be used as a grammar correction tool ('massive puzzle' => 'Massive Puzzle') so all themes appear consistent on the site.

@Eremiell mentioning theme approvals is not necessary in the rules. The way it is done may change and really should not have an affect on the outcome of the jam. It was added simply to avoid the problem of having generic/uninteresting/bad themes in the voting rounds.

Why are game voting categories only known at the beginning of the game voting phase? (Name that differently, to not confuse it with theme voting). If the developer is left in the dark regarding what matters in the end, he can't optimize his game accordingly. For example, if "closeness to the theme" is not one category, the whole point of adhering to the theme is defeated.

I worded this part this way, because even I have no idea, how far this is in implementation and what are zsbzsb's intentions with it. My idea about it is pretty much copy-paste what LD got, but we can discuss the categories. I believe zsbzsb should be able to add or remove categories pretty much on go, but last time we were talking about his feature, it was something yet to be implemented.

Categories in LD are hard coded into their site, its always the same for every jam. That said, I can make categories customizeable per jam - but they would be announced with the jam. There is no reason to withhold that information from anyone.

[Eremiell]

Firstly, sorry it took me some two more days than expected, other stuff got in my way. Will try to reserve a bit of my time every morning for this from now.

I tried to restructure the rules a bit, which could hopefully bring more clarity and everyone should have clear idea which rules are important for them at any phase. In the end, there's now even slightly more rules, as some old rules needed to be split into several phases, but I think, it's much more readable now and gives better idea about phase progression and what applies when.

Also tried to get rid about any fixed time units anywhere in the rules besides the initial Time Frame section, so it could be easily edited for different durations.

Cleaned up the style a bit too, got rid of all you/your and replaced it with participants/the. Project/game and similar got normalized to entry to allow maximal creativity. Do whatever you want, even if it might not feel like hitting the "game" lable in your mind. (But note generic media player will probably not do very good in the final judging.)


Time Frame:
1. The jam starts with theme polling, with 48 hours for theme proposal and another 48 hours for theme voting.
2. The theme of the jam is announced 24 hours before the jam officially starts, and everyone is encouraged to use this time for brainstorming ideas. No work should be done yet.
3. Participants are given 16 days of jamming (Saturday midnight UTC to Monday midnight UTC) to work on their entry.
4. Additional 48 hours are given to participants for packaging the entry. No major development should be done in this time.
5. Everyone has 12 days to try the entries and cast their votes in final judging.
6. Together start to finish, the jam takes 5 weeks. Most of the participant's activity is expected in the 16 days of jamming.

Theme Polling:
7. Each participant (person intending to try to make an entry during the jamming phase on his own or in a team) is allowed to take place in theme polling. Non-participants are asked to abstain from theme voting while their input is welcome in theme proposal.
8. During theme proposal subphase, everyone's welcome to propose theme ideas.
9. Theme ideas must not be offensive, vague, too similar to theme of any previous SFML Game Jam or recent iterations of any major game jam and must make sense.
10. During theme voting subphase, the theme ideas will be voted on in several rounds.
11. Each round each participant has limited amount of votes decided by organizers based on amount of received theme ideas. The number of votes as well as the number of rounds will be known to participant at the beginning of the first voting round. Number of votes will be the same in all rounds including the final round.
12. Votes can be used to cast positive or negative points on ideas in the given round.
13. Theme ideas with best scores from each round will progress to the final round. Winner of the final round will be announced as the jam theme.

Theme Announcement:
14. Participants are free to publicly or privately brainstorm entry ideas and form teams. No actual work on the entry should yet be started.
15. Participants can continue to do whatever they're normally doing even if that would be useful for their jam entry, but they shouldn't specifically work on the entry itself.

Jamming:
16. Paticipants can work in a team of any size, or by themself. Any participant is allowed work on several teams or entries (like asset creators can provide music or graphics for several entries, etc.).
17. Participants should only create any original work needed for their entry during this phase.
18. Any programming language may be used, as long as SFML (or one of its bindings) is used.
19. External libraries are allowed, but not SFML's competitors, such as GLFW, SDL, Allegro, etc. The use of OpenGL is allowed, however.
20. Any additional resources are allowed as long as participants have rights to use them, but they shouldn't be presented as original content created for the jam. Previous rule is the only limitation to this.
21. Participants have to give credit to original authors of any resources they use, that are not their own, even when the license doesn't enforce that. (Mostly so it's clear what is and what isn't their work.)

Delivery:
22. Team size and members must be stated when submitting.
23. A link to source is required when submitting as well as link to assets/anything needed in addition to compiled source in ready to use form (archive with expected directory structure, directory with expected contents and subdirectories on some cloud storage service, ...).
24. Source and any assets created for the entry has to be release into Public Domain or under permissive or copyleft license if that's possible. Participants are encouraged to use permissive license for maximal reusability of the work. Recommendations for participants without prior understanding on licensing are provided [here] (imagine link to the previous text, probably slightly edited), but are not part of these rules in any way.
26. A link to a working version of the entry for either Windows, Mac, or Linux is required when submitting. This must include the executable and all assets/extras needed to run the entry.
26. Entries with NSFW or shocking content must be marked as such.
27. Porting to other OS's as well as fixing small bugs in the entry and any issues with the packaging is allowed and encouraged.
28. Particpants are allowed to continue work on their entry, but they have to keep the version made during the jamming phase (with exceptions per previous rule) for final judging.

Final Judging:.
29. Everyone with an account of the jam site has right to vote (even non-participants).
30. Final judging takes place in several categories, that will be known to everyone at the beginning of the jam.
31. Participants can decide to not take place in judging for some categories for any reason. Participants who didn't create any original content in given category are encouraged to do so.
32. Porting to other OS's as well as fixing small bugs in the entry and any issues with the packaging is still allowed and encouraged.
33. Participants are allowed to continue work on their entry, but they have to keep the version made during the jamming phase (with exceptions per previous rule) until this phase is over
34. Winner in each category as well as overall winner will be announced once the final judging is over.


I'll leave it here for comments, will come back later tomorrow to discuss terms. The time is slightly running up and we might concider even a later term after the LD.

EDIT: Renamed Final Voting to Final Judging to further differenciate from Theme Polling, which still has Theme Voting as subphase.

[Eremiell]

Ok, let's look at the terms.

First, LD recapitulation, as it's what kinda limits our possibilities.

Next LD comes 15-18 April. Their theme proposal start 5 weeks before that, which is 11 March, theme voting 3 weeks later which is first April and their final judging goes for 3 weeks, meaning 9 May.

Now for most participants the most crucial time will be in both LD and SFMLGJ the actual jamming time, but the rest is important as well. Everyone likes to have a word about the theme and the final judging serves as promotion. So we'd like to minimize any overlapping and maximize the gap between the jamming parts.

From another point of view, we'd like maximize the participation, which means both getting some some promotion outside this forum on SFML IRC and letting people prepare for the jam.

OK, let's revisit the terms proposed last time:

	Theme proposal	Theme voting	Theme announcement	Jamming	Delivery	Final judging	Winner announcement
1)	15. Feb - 16. Feb	17. Feb - 18. Feb	19. Feb	20. Feb - 6. Mar	7. Mar - 8. Mar	9. Mar - 20. Mar	21. Mar
2)	22. Feb - 23. Feb	24. Feb - 25. Feb	26. Feb	27. Feb - 13. Mar	14. Mar - 15. Mar	16. Mar - 27. Mar	28. Mar
3)	29. Feb - 1. Mar	2. Mar - 3. Mar	4. Mar	5. Mar - 20. Mar	21. Mar - 22. Mar	23. Mar - 3. Apr	4. Apr
4)	7. Mar - 8. Mar	9. Mar - 10. Mar	11. Mar	12. Mar - 27. Mar	28. Mar - 29. Mar	30. Mar - 10. Apr	11. Apr

The first one's clearly out of question, too soon. The second one kinda as well. The later two might still be viable.

Alternative would be going after LD. That would mean probably something like:

	Theme proposal	Theme voting	Theme announcement	Jamming	Delivery	Final judging	Winner announcement
5)	9. May - 10. May	11. May - 12. May	13. May	14. May - 29. May	30. May - 31. May	1. Jun - 12. Jun	13. Jun

Which seem kinda late, if you ask me.

So my proposal right now is to go with number 3). That means some 3 weeks from now before the theme polling, roughly 4 weeks to start of jam, which should give us some tim to prepare and advertise and with the jamming phase ending 20. March, that gives roughly 3 weeks to the LD with our final judging ending slightly into their theme voting.

Comments welcome, if there are none before Sunday, we'll move forward with this.

EDIT: Reflected the change of Final voting to Final judging.

[Nexus]

Nice work, thanks for the fundamental restructuring! It's really much clearer, now that phases are separated.

Some comments:

• Polling = proposal + voting? To increase clarity, I would suggest to omit the term "polling" entirely and split proposal and voting phase. The separation would make clear that the two phases are done after each other, not in parallel.
• There are still some duplications, like "No work should be done yet." or "No actual work on the entry should yet be started." Maybe the time frame should only give an overview over the phases, while each of them is explained in its respective section.
• Little typos:
  "Source and any assets created for the entry has to be release" -> "Source and any assets created for the entry have to be released
  "Particpants are allowed to continue" -> "Participants..."
  "until this phase is over" -> fullstop at end
• "Entry" sounds very abstract, it might confuse more than it helps. "Game" would be okay in my opinion, and otherwise "project" would still be generic enough. But anyway, this is a really minor point, we can also leave "entry".

If you'd like, you can also post this on the SFML Wiki so I can help editing. But I think it's almost finished anyway.

[eXpl0it3r]

3) seems fine to me.

[Eremiell]

Battling the time again, those dastardly deadlines. Lucky us the system watches the jam deadlines, so it won't get two days late just because I had to finish the movement code in time.

I'll incorporate the latest set of proposals hopefully tomorrow (Tuesday CET time) and we'll get the beast moving.

[Eremiell]

OK, (final?) draft of the rules? I honestly liked the entry more, but let's compare. I'm up to edit it back if needed.


Time Frame:
1. The jam starts with 48 hours for theme proposal.
2. Another 48 hours are given for theme voting.
3. The theme of the jam is announced 24 hours before the jamming officially starts.
4. Participants are given 16 days of jamming (Saturday midnight UTC to Monday midnight UTC) to work on their projects.
5. Additional 48 hours are given to participants for packaging the projects and delivery.
6. Everyone has 12 days to try the projects and cast their votes in final judging.
7. Together start to finish, the jam takes 5 weeks, all phases follow each other immediately. Most of the participant's activity is expected in the 16 days of jamming.

Theme Proposal:
8. Everyone with an account on the jam site is welcome to propose theme ideas.
9. Theme ideas must not be offensive, vague, too similar to theme of any previous SFML Game Jam or recent iterations of any major game jam and must make sense.

Theme Voting:
10. Each participant (person intending to try to make a project during the jamming phase on his own or in a team) is allowed to take place in theme voting. Non-participants are asked to abstain.
11. The theme ideas will be voted on in several rounds.
12. Each round each participant has limited amount of votes decided by organizers based on amount of received theme ideas. The number of votes as well as the number of rounds will be known to participant at the beginning of the first voting round. Number of votes will be the same in all rounds including the final round.
13. Votes can be used to cast positive or negative points on ideas in the given round.
14. Theme ideas with best scores from each round will progress to the final round. Winner of the final round will be announced as the jam theme.

Theme Announcement:
15. Participants are free to publicly or privately brainstorm project ideas and form teams. No actual work on the project should yet be started.
16. Participants can continue to do whatever they're normally doing even if that would be useful for their jam project, but they shouldn't specifically work on the project itself.

Jamming:
17. Participants can work in a team of any size, or by themselves. Any participant is allowed to work on several teams or projects (like asset creators can provide music or graphics for several projects, etc.).
18. Participants should only create any original work needed for their project during this phase.
19. Any programming language may be used, as long as SFML (or one of its bindings) is used.
20. External libraries are allowed, but not SFML's competitors, such as GLFW, SDL, Allegro, etc. The use of OpenGL is allowed, however.
21. Any additional resources are allowed as long as participants have rights to use them, but they shouldn't be presented as original content created for the jam. Previous rule is the only limitation to this.
22. Participants have to give credit to original authors of any resources they use, that are not their own, even when the license doesn't enforce that. (Mostly so it's clear what is and what isn't their work.)

Delivery:
23. Team size and members must be stated when submitting.
24. A link to source is required when submitting as well as link to assets/anything needed in addition to compiled source in ready to use form (archive with expected directory structure, directory with expected contents and subdirectories on some cloud storage service, ...). Additional libraries should be listed and providing precompiled binaries or ways to obtain or compile them is encouraged.
25. Source and any assets created for the project have to be release into Public Domain or under permissive or copyleft license if that's possible. Participants are encouraged to use permissive license for maximal reusability of the work. Recommendations for participants without prior understanding on licensing are provided [here] (imagine link to the previous text, probably slightly edited), but are not part of these rules in any way.
26. A link to a working version of the project for either Windows, Mac, or Linux is required when submitting. This must include the executable and all assets/extras needed to run the project.
27. Projects with NSFW or shocking content must be marked as such.
28. Porting to other OS's as well as fixing small bugs in the project and any issues with the packaging is allowed and encouraged.
29. Participants are allowed to continue work on their project, but they have to keep the version made during the jamming phase (with exceptions per previous rule) for final judging.

Final Judging:
30. Everyone with an account of the jam site has right to vote (even non-participants).
31. Final judging takes place in several categories, that will be known to everyone at the beginning of the jam.
32. Participants can decide to not take place in judging for some categories for any reason. Participants who didn't create any original content in given category are encouraged to do so.
33. Porting to other OS's as well as fixing small bugs in the project and any issues with the packaging is still allowed and encouraged.
34. Participants are allowed to continue work on their project, but they have to keep the version made during the jamming phase (with exceptions per previous rule) until this phase is over.
35. Winner in each category as well as overall winner will be announced once the final judging is over.


Let's assume no major changes will be made. We're still open for comments, but mostly small fixes.

Also let's fix the dates and start promotion.

	Theme Proposal	Theme Voting	Theme Announcement	Jamming	Delivery	Final Judging	Winner Announcement
3)	29. Feb - 1. Mar	2. Mar - 3. Mar	4. Mar	5. Mar - 20. Mar	21. Mar - 22. Mar	23. Mar - 3. Apr	4. Apr

I'll slightly edit the license recommendation text and make new thread for the jam announcement and another one for the recommendations. Let's make this large.

[Godsend72]

The results or the next jam — which comes first, we never know.

[Jonny]

The results or the next jam — which comes first, we never know.

or neither...