Gamers' Plane Heroes Needed (Inquire Within)

Hello Gamers' Plane Community!

As you may know, Adam and the development team have been working hard to bring many new features and bug fixes to our platform. Huge thanks to them! But they need more than appreciation; they need our help.

We are looking for users of all experience levels to test out new features and report back on bugs and oddities that you discover. For those of you who aren't developers, it is a MASSIVE help to have somebody else test the features you built. A programmer has their own biases and blind spots. When the features go live, users will do unexpected things causing the development team to exclaim "Wow I never expected a user to do THAT!" It's just not possible for developers to think of all these things.

We are also looking for users who are able to document these features. We are finding that many people in our community are unaware of the new features and have questions about how to use them. We are not all coders but we are all writers by nature of our hobby! Let's write explanations and tutorials that showcase these new features.

If the community can take charge of these two jobs, it will be a MASSIVE help to our developers. These are big jobs, but when spread across a whole team of testers and writers, it can turn into many manageable jobs. Not only will we free up the developers' time to write more and better features. Also, our devs are only human, and the burden of coding and testing and documenting is a heavy one. We're not all coders but these are skills that we have in spades in this community.

If you would like to answer the call, make a comment below with your preference of what effort you'd like to throw your weight behind (testing, writing documentation, or both).

Hi I'd be interested in helping. I don't know much about Coding and Programming, but I could try to test out features. Not sure what you all need, but I can try thanks.

I'm always game to help the folks here at GP.

I can test and/or write some documentation.

I would also be happy to help. Testing and perhaps writing but I don't know what is needed.

I'm willing to test things.

I'd be happy to help, and almost always am. However, I answered a call like this years ago helping proofread some documentation prepared by naatkinson and Keleth, volunteering to become a moderator, but then most of the assistance with the site since then has been oriented around programming/coding.

Crowd-sourcing is great, but it might help if there were specific projects mentioned for GP's evolution. From discussions among GP's brain trust, what's missing from the site? A lot of people would be happy to lend a hand, but since we aren't all adept at coding maybe a couple of ideas unrelated to the backend of the site could be helpful.

I don't want this to come off as confrontational; it's just an observation on how we might be better able to offer assistance.

Thanks for bringing this up @Phil_Ozzy_Fer .I'm surely non-code savvy myself. I do have ideas spawning randomly though. Perhaps The Coucil of Elrond could expand in the way you're describing, or another think tank could be created. I don't believe that there's an intention of excluding anyone really.
There even was a change of guard in the council recently.

Thanks to everyone for the offers of help. Bear in mind - I'm not a site admin - I'm a gamer here to PbP, just like you.

Firstly - Please, anyone, everyone - let us know about bugs, ideas for improvement, problems you find with the site, suggestions, spelling mitsakes. There's no special role for having ideas, suggestions or reporting bugs. I can promise not all bugs will be fixed, or ideas implemented, sorry about that.

Secondly, We have two staging sites.
There's one for changes that are under active development. That's the site to look at BEFORE changes go live, i.e. when changes can still be changed. I update most of the data on it fairly regularly so you can see it with your own accounts and try things out.

There's another site for testing out server configurations. This is the one to catch the show-stoppers that can poleax the release (e.g. if the database doesn't support a feature that's been used in development).

There's no special role for accessing these staging sites. Testing isn't just about checking whether a feature or tweak works - it's also about whether it makes the site better. I'd quite like to capture people's feedback though, maybe something like a poll so we know who's looked at features and whether they're happy with them, something like that.

Lastly, there's a group of people, community representatives, the Council of Elrond, who decide which features should go live and sign them off. At least that's the idea. I've done a sucky job of managing that. I'd love someone to take over that role - corraling the community reps into a consensus.

So the process is:
1. Ideas come from all over the place.
2. We look at what can be done, and if it's easy - there's an initial discussion with the community reps on whether it's a good idea.
3. It goes onto a preview site.
4. If that looks good, then a group of people who decide if we should ask for it to be merged with the codebase.
5. Ultimately, all code goes through Keleth - and he has the final say on any feature. It's his house, and his vision - but I believe that he will listen to your opinions.

---

Okay. That's the outline. Time for some practical steps.

1) If you see a bug, then report it in the bugs forum.
2) If you have a suggestion or idea, then I guess post it in the bugs forum too, but prefix it with Suggestion:, Idea:, or something.
3) Someone needs to work out how to capture feedback from people who have looked at staging, and how to get sign off for releases. Sort of like a project manager, but without the gantt charts or any pay.
4) Once 3 is done, then I guess that person will tell y'all what to do next.

Any data on mapdm will get nuked whenever I update the site (approx weekly).

We need a place to store public feedback that isn't on the site. Let me create a thread in site development for feedback.

How about https://staging.gamersplane.com does it get wiped as well?

I don't know. I don't manage that one. I wipe the data on the early staging so that people can look at it with their current games.

I plan on updating that with copies of the prod database less frequently. Maybe once a month or with major features.

First off, thanks everyone for expressing interest in helping! As you can see, there is some amount of uncertainty on how to proceed. Bugs and minor fixes are fairly straight forward, but what's next?
So, I'm going to throw some ideas out there. I don't expect everyone to agree with them, and I'm not sure they're right myself, but these are my $0.02.

I really think we need to slow the feature production WAY down. We're talking 2015 era D&D 5e hardcover release schedule kind of slow. Just like play by post is inherently slow. Really, really slow. Thoughtfully slow. I think 5e has done a great job of slow-rolling it's splat books and I suggest we do the same for new features.

I know what the hurry was - there were some important quality of life updates that users wanted. Things like making the site work better on mobile devices. Things like getting email to work right. Things like fixing user profile so they aren't reinforcing gender binaries.

But, now the site is looking really sharp and we moving into an era of would-be-nice features. Adam is finding that people aren't even taking the time to read about the features that are coming out. Sometimes they are surprising people, and they are confused/puzzled about them.

I think we should slow down to a 6-ish month release schedule. Just like 5e hardcovers, our releases should be bookended by surveys and data collection (think Unearthed Arcana and the satisfaction surveys), and have sufficient hype so that users know what's coming. I think this will allow the process to be, at all levels:

* Community driven
* Sustainable
* Gradual
* Visible
* Accountable

Here's the steps as I see them...

Step 1: Survey The Community: Big, comprehensive survey from the community about their experience with the site. We plan this out thoughtfully and carefully, think about how to word questions so as to make the data useful. Get many eyes to look it over.

Step 2: Form an Action Plan: From the survey we identify the biggest challenges or important wishes that the community has. We should be prepared that no action may be a possible outcome of the survey. We publish the action plan before code is written announce the new features that are coming up in the next release.

Step 3: Develop / Test / Document Cycle: Devs get cooking and stage the new features on the test servers. Testers have considerable time to experience the staged site. Like, testers should run a whole vignette game together with the new features on the staged site. Devs and testers discuss and make changes together. The cycle continues until the goals are realized and the testers sign off on the stability and usability. It is possible that through testing we discover the idea isn't good and that should be a possible outcome of this stage.

During this process, regular community updates are given about how its going. Before features are released, the documentation needs to be finished. This might take the form of release notes, video tutorials, or what not.

Stage 4: Publish changes on gamersplane.com: The new changes go live. We focus on minor bug fixes and tweaks for an extended period of time before we start over with a new survey, which includes checking satisfaction with the last release.

I see us slowing down to doing this cycle maybe once or twice a year. Play by post is inherently slow, and I think this process should be too. It doesn't have to be quite so rigid as I described above; but I wanted to get my ideas straightened out into clearly delineated stages before we have to be practical about it.

Okay, there's my $0.02.

I like the idea of slowing things down. The issues we heard about six months ago were: the site not being mobile-friendly, people reminiscing about the good ol' days when they could easily find public games, not being able to get to page 2 of the latest posts, onboarding issues. GP needed a bit of spring clean, but that's largely done. Major/minor release cycles can now kick in.

---

The way that new features are being developed is now different too. They're more granular. This means that staging can have all the new stuff for evaluation, testing, documenting, and the community can decide what should be included in a release.

Think of GitHub like a store.



The devs are going to put stuff in the store.

We'll stock the GitHub shelves. The items will have catalogue references like "tweak/advanced_post_preview". You can test drive the items on staging before choosing to put them in your release basket. Maybe you want an express delivery of a bug fix.

But what's picked, when you choose to order, how to communicate your release basket with the community - that's what you heroes are for. Can I leave organising that side of things to you @Len?

Agree 100% with Len. Love the core fixes and the new stuff, but it's going to take real time for the community to come to grips with everything that's changed. Would love to see bug fixes continue, perhaps monthly? Then maybe quarterly or biannual updates for new features, as Len suggests.

In the end, awesome job to all involved. I don't know if many people understand just how stagnant RPG PbP web technology can be, but what we've witnesses in terms of changes over the last few months has been nothing short of astonishing. Major kudos to Adam, to Keleth, to the mods, the council and others testing and providing feedback. Seriously good stuff. Fabulous finish to 2021 for GP.

So, one thing I'm gonna do is setup release schedule. To help with this, we'll do features no more than twice a month, at least two weeks apart. Bug fixes and the like will come more often. The GP staging server is up, and we'll get releases up on staging for at least two weeks before release to production, which will give people time to look at it and provide feedback. How does that sound?

Great! But the change management is the stuff that might need a little TLC. Which people are talking about elsewhere, with videos and such...

What in particular?