Making it public

This page is about what happens after you have released a version: how you ask for a review of it, who approves it, how it becomes the public version, and what can be undone.

⚠ Read the Who approves it section before you ask for a review. The request has a real consequence, it sends a notice to the team, and it cannot be taken back.

Two separate steps

A release and being public are not the same thing, and they do not come together either:

A release (New release): a snapshot of the draft’s components. That makes the version exist, a party can be started on it (by you and by the people you shared it with), but nobody from the outside sees it. The Draft and versions page describes that.
Making it public: you declare that an already released version is “the” version. For that the game, not the version, needs an approved review.

So you have to get the review once, on the game; after that you can make any released version public without a further request.

Where you find it

The Review card is in the right-hand column of the Releases page: the state’s tag in it, a short explanation, and, if you can ask right now, the Request review button.

The same state appears as a tag on the newest live release’s row as well, because that is where making it public is decided.

The last point of the Overview page’s Ready to release? list is this too: Approved for public play, and the Fix this button brings you straight here.

The four states

State	What you see on the card	What you can do
no request	`Not reviewed`: “A version can only be made public after we have reviewed the game.”	Request review
pending	`Review pending`: “We are looking at your game. This usually takes a few days.”	wait
approved	`Reviewed`: “You can make any release public.”	`Public` is live in the Visibility menu
rejected	`Review rejected`: “Fix what we wrote to you, then ask for a new review.”	Request review again

Until the state is Reviewed, the Public item of the Visibility menu is greyed out, and the reason stands under it: “A public version needs an approved review.”

⚠ The reason for a rejection does not show in the Builder. The card only says to fix what we wrote: the feedback is in the message that arrives in your account, not here.

⚠ The card does not refresh by itself. It reads the state when the page opens. If you leave the Builder open while the review is going on, the approval will not appear: reload the page.

Requesting a review

It starts from two places, and they are the same two: the button on the Review card, and Request review in the ”…” menu of a release’s row.

After you press the button, a brief Sending the request… shows, then the Review requested. confirmation, and the state switches to pending.

Two things happen then:

The game’s state goes to pending.
The team gets a notice about the game and about you, and the review starts with that.

⚠ The request cannot be taken back. There is no “never mind” in the interface: once you have sent it, the state stays pending until somebody sets it over by hand. So only ask for a review on a real game if you really want to.

While the review is pending, or once it has been approved, the menu item and the button are greyed out: you cannot ask twice.

Only the game’s owner can ask for a review

The server ties the request to the game’s owner. If you reached the game through a group or an organisation, it turns the request down even if you can otherwise edit the game.

If the request does not go through, the interface says what went wrong. If you are not sure the game is yours: the Access page only appears for the owner, which is the simplest test.

Who approves it

The GreenCloth team decides on the request, outside the Builder. The approval happens by hand, and there is no button for it in the Builder or in any other interface you can reach.

What of that concerns you:

There is no promised turnaround. The card says only that this usually takes a few days.
The feedback arrives in your account, as a message; the account row in the sidebar then shows an unread-message indicator. The state itself shows on the Releases page, and only if you reload the page.

Making it public

After an approved review, the Public item of the Visibility menu is live on the row of every non-deprecated release.

What it does: it sets on the game that this is the current version. The row gets a Public tag, and the interface confirms it: “The version is public now.”

Exactly one version at a time can be public. Make another one public and it takes the place over from the previous one, you do not have to take that one off first. This sentence stands under the menu as well: “One version at a time can be public.”

While a version is public, it cannot be deprecated: Deprecate in the ”…” menu is greyed out, and the help text says why.

Taking it off public

The Not public item of the Visibility menu ends the public state: from then on the game has no designated current version. There is no confirming question, the menu item acts at once, and the interface only confirms: “The version is not public any more.”

The version itself is left intact; it can be made public again at any time, and you do not have to ask for the review again either.

What happens to running parties

Running parties carry on working. Neither taking it off nor deprecating it breaks them off. The interface spells that out in the deprecation question: “Running parties keep working.”

Why: a party picks a version when it starts, and remembers which one. From then on it asks for the content against that version, even if the server restarts in the meantime. And released versions are never overwritten and never deleted, only their state changes.

What all of this affects is the next party: which version loads when it starts.

There is a public version → that one starts.
There is not → the newest, non-deprecated release starts.
There is no release at all → the draft starts. That is how you can try your own work without a release.

What “public” means in practice

What making it public certainly does:

It designates the parties’ default version, see above.
It opens the version to outsiders. For anybody who is not the owner and does not reach it through a group or an organisation, the public version is the only one of the game’s versions that exists. While there is no public version, not one version is visible from the outside.

What it does not do, though its name would lead you to expect it:

⚠ The game does not get into the controller’s game chooser because of it. The chooser shows the list the game’s access allows: your own games, and whatever you reached through a group. Making it public opens a version, it does not make the game discoverable. So if the aim is for somebody to find the game, add it to a group, see Playtest group.

⚠ The branded game page does not live off it either. A game page tied to your own domain shows the game the domain belongs to, and does not look at whether it has a public version, see Brands.

A usual run of things

The draft is ready → a release.
Try it: start a party with the game, look at it on the display and on the controller. It works without a release as well, and then the draft starts.
Fix things if you need to, and put out a new release. The old ones survive.
When the game is in a releasable state: Request review. That is a one-off step on the game.
After approval, Visibility → Public on the version you mean the parties to have.
On later releases only step 5 repeats: you do not have to ask for the review again.