Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account

Allow Sheet Authors to make Custom sheets

Score + 98
1749253969
GiGs
Pro
Sheet Author
API Scripter
Nurgleth said: I wanted to make some updates to an existing sheet that is showing its age and was very surprised to realise that there was no way to test anything. I was even prepared to spring for Plus, even though it has no incentives that interest me, but paying 10 bucks for the privilege of doing free labor is too much. It's disappointing to see that this issue is almost 10 years old. There is a way to test changes, but you have to be a Pro subscriber. That's irritating.
1749254601

Edited 1749254628
vÍnce
Pro
Sheet Author
Just to add... while not ideal, a person can pick a Pro subscription just while they develop a sheet.  Once a sheet has been added to the roll20 repo it will available regardless of the subscription level.  To be clear, I'm on the side of allowing anyone that want's to develop a sheet, to do so without paying for Pro.  Maybe Roll20 could offer something something like a "limited" Pro account just for developers.  IDK
1749290903

Edited 1749290923
GiGs said: There is a way to test changes, but you have to be a Pro subscriber. That's irritating. Yes, sorry, that was me being vague - I meant, no way to test anything with my Base account. I think the Custom Sandbox is a great tool and since it has no value to any user who isn't developing a sheet, it doesn't seem like there is a solid reason not to make it available to other tiers. If the intent is limiting pull requests then that seems like a counter-intuitive way of going about it - if the site makes its money with subscriptions, then one of its features shouldn't rely on not having too many, right? Andreas J. also made some (imo) good suggestions for solving that in a comment earlier: Giving preferential treatment to community/peer-reviewed Pull Requests (i.e. someone have checked the PR and given an approval) Giving a limited number of community contributors "triage" level access to the repo, granting them the options to open/close PRs/mark as duplicates, assign issues/labels, make PR review request.