Tossing these two together for some discussion as they somewhat relate. I'll try to keep it relatively brief to encourage discussion rather than overwhelm, but I'm still me ... 
Will use section spoilers to cut down on initially perceived heft ...
Ooookay. Yeah that's still long. Sorry! Thoughts? Aiming to post one of these threads per day I'm off, hah!
Will use section spoilers to cut down on initially perceived heft ...
Overview
Recently a brief discussion on IRC with Marcin Sciesinski and synopia made me wonder about our feature development process and the products, for the latter specifically about maturity levels / versioning. At the same time mkalb has been playing with version info for the launcher, changelogs, and so on. GitHub also just introduced Releases. Finally UberWaffe has also brought the use of MoSCoW analysis into the mix.
Marcin's point was that if he didn't feel like designing, just implementing, there isn't much to simply pick up for L&S. Even with MoSCoW applied a lot is left up to the imagination of the implementer. It is more for high level analysis and prioritization than explaining in detail how a gameplay feature should actually work - like a victory condition. Expanding on / formalizing our process a little brings me to the following
Recently a brief discussion on IRC with Marcin Sciesinski and synopia made me wonder about our feature development process and the products, for the latter specifically about maturity levels / versioning. At the same time mkalb has been playing with version info for the launcher, changelogs, and so on. GitHub also just introduced Releases. Finally UberWaffe has also brought the use of MoSCoW analysis into the mix.
Marcin's point was that if he didn't feel like designing, just implementing, there isn't much to simply pick up for L&S. Even with MoSCoW applied a lot is left up to the imagination of the implementer. It is more for high level analysis and prioritization than explaining in detail how a gameplay feature should actually work - like a victory condition. Expanding on / formalizing our process a little brings me to the following
Feature Analysis
Idea is that features get analysis added only as needed (although we might need a little alpha/beta/rc tracking for versioning)
Idea is that features get analysis added only as needed (although we might need a little alpha/beta/rc tracking for versioning)
- Features that are driven entirely by an invididual (like Synopia's pathfinding) don't really need MoSCoW analysis, at least not at first. Wouldn't necessarily help the implementation / matter for a while since the author knows exactly what to do (feedback & suggestions are still good)
- Features that get suggested but don't have a motivated individual driving it or is still too vague to start on should have MoSCoW added to at least get a better overview. I hope UberWaffe will be able to keep doing this occasionally as an overall Analyst
- Features that still don't have a dedicated implementer or remain vague can get the MoSCoW expanded by a related Game Designer - best current example is SuperSnark being top organizer for L&S (talked to him about this and he's OK with being "Game Design Lead" for L&S and fleshing out threads - Design badge added!)
Development Maturity
A big advantage of the MoSCoW so far has been the prioritization (Must, Should, Could, Would) and furthermore splitting that into 3-4 phases. I think that would be good to aim for in general to better judge where we're at as well as to help version content. Good example here.
A big advantage of the MoSCoW so far has been the prioritization (Must, Should, Could, Would) and furthermore splitting that into 3-4 phases. I think that would be good to aim for in general to better judge where we're at as well as to help version content. Good example here.
- First bare-bones version: Pre-alpha ("Experimental" ? "x") purely for getting started and testing some contents, not playable yet. Really just a first goal post to aim for.
- First playable version: Alpha ("a") with actual content that can be played through, still might contain holes. Should be tracked a little more carefully after this point
- First releasable version: Beta / release candidate ("b" or "rc") that is polished enough for normal users. Release candidates may be spun off for acceptance of some sort.
- Released: 1.0.0 (not a MoSCoW phase as much as a stage / milestone). After this point we're on the hook for full API docs and change tracking if appropriate.
Hierarchical Design
On top or prioritizing and phasing stuff better we've also got some trickiness organizing between the different scopes of the project - Terasology the game --> Game Modes --> (mods) --> Modules --> (sub-module level). Right now most the MoSCoW is hitting what will become individual modules plus the L&S game mode itself. Could formalize and connect that better yet:
Finally engine work is sort of separate from all this. World Gen is sort of in that boat too at the moment - maybe something to treat in a similar fashion to a game mode with Nym Traveel
on point, but not exactly the same. Likewise for Immortius on multiplayer. I know Xenforo has a thread prefix addon we might want to use on Incubator threads to better mark them than the single "Scope" field in the header template
On top or prioritizing and phasing stuff better we've also got some trickiness organizing between the different scopes of the project - Terasology the game --> Game Modes --> (mods) --> Modules --> (sub-module level). Right now most the MoSCoW is hitting what will become individual modules plus the L&S game mode itself. Could formalize and connect that better yet:
- Modules are currently our smallest pieces and their MoSCoW doesn't sub-divide (yet). They each (should!) get a thread in the Incubator forum with analysis applied (if needed/desired)
- We might possibly hit modules big enough to consider splitting out pieces in the future. Independent Incubators are possible as long as they get linked well enough. Example: World Gen is a big topic and already has several poorly linked threads.
- Game Modes are for binding a series of Modules together. We really could do this with the MoSCoW as well, providing a high level analysis in the Game Mode thread that talks of independent incubators as line items? A Game Designer Lead should be tagged for each game mode; they will be important milestones for overall game progress. If the Game Mode has a specific art style maybe an art lead could be tagged specific to that sub-project rather than for all the things (which hasn't worked so well yet)
- Modules are ultimately meant to be smaller pieces than traditional "mods" - for example the "oreominions" module just contains some models meant to be used by "miniions" which is more "mods" sized. Dunno if that's another layer to the analysis/structure between Game Modes and Modules
- The whole of Terasology the game really could itself go through MoSCoW as well, giving us a better idea where we are for our global alpha-beta-released status. Again line items would probably relate to other Incubators (some of which could be entire game modes). Alpha probably would depend primarily on L&S plus develop/multiplayer convergence including module restructuring.
Finally engine work is sort of separate from all this. World Gen is sort of in that boat too at the moment - maybe something to treat in a similar fashion to a game mode with Nym Traveel
on point, but not exactly the same. Likewise for Immortius on multiplayer. I know Xenforo has a thread prefix addon we might want to use on Incubator threads to better mark them than the single "Scope" field in the header template
Version All The Things
Plenty of stuff above has referenced release levels which is something we haven't really done for some time now. I was arbitrarily assigning version numbers to stable branch builds in the past, but it had no meaning. mkalb in particular has paid attention to this topic lately related to use in the Launcher and its tracking of the changelog of the primary project. I wonder if he might be interested in stepping up to become a Release Manager of sorts, helping keep track of all the numbering, dependency tracking, and Jenkins/Gradle fun?
Semantic Versioning ("semver") seems a good convention to follow and we might want to sort out what to us matches the different aspects of it. My thoughts:
One tricky bit is that if we involve the Jenkins job build numbers we must only use it from one job per repo, and keep master/develop branches in sync. Otherwise a Terasology unstable (pre-release) build from develop would speed ahead in patch number vs a stable build from the master. Would have to ignore the master build number and simply take off the pre-release token when pushing changes forward from develop to master. Say Jenkins develop build 123 would create 0.5.123-alpha; push to master and that would become 0.5.123 (but then would lose the informative "alpha" status ... wah, this is hard)
Edit: I'm thinking more about how semver really wants the alpha/beta pre-release stuff to happen betweeen natural releases (1.0.1-alpha, 1.0.1-beta, then 1.0.1 and afterwards work begins on 1.0.2-alpha) not alongside natural releases (1.0.1-alpha, 1.0.2-alpha, then 1.0.2 - no formal 1.0.1 release) But the magic 0.y.x period really is entirely "pre-release", so I wonder if it what I'm outlining above makes sense, then at 1.y.x you swap to alpha/beta/rc being entirely between natural releases.
Plenty of stuff above has referenced release levels which is something we haven't really done for some time now. I was arbitrarily assigning version numbers to stable branch builds in the past, but it had no meaning. mkalb in particular has paid attention to this topic lately related to use in the Launcher and its tracking of the changelog of the primary project. I wonder if he might be interested in stepping up to become a Release Manager of sorts, helping keep track of all the numbering, dependency tracking, and Jenkins/Gradle fun?
Semantic Versioning ("semver") seems a good convention to follow and we might want to sort out what to us matches the different aspects of it. My thoughts:
- Version all the things separately when we split them out - got a big draft nearly ready for review and feedback there. Seems obviously needed anyway to track module dependencies and such.
- Use the master/stable branches much more. Builds from there get natural version numbers (no pre-release tokens) and matching GitHub releases
- Anything from a develop branch is a pre-release build and gets the semver pre-release token + pre-release checkbox on GitHub. The pre-release token matches the stage of the MoSCoW we're in (so "alpha", or "a" or "rc" and so on, possibly with a number tagged on)
- Challenge: Experimental builds ("x") would sort as more mature as alpha/release candidates unless we find a better prefix. Alternatively the length of the prerelease token can be used too - experimental < alpha < beta < rc
- I'm feeling tempted to use the Jenkins build number after the first pre-release token, i.e. 0.5.0-alpha.25. This makes me feel guilty as it seems to go against the semver convention saying build metadata should be at the end after a +
- Exactly how to correspond Jenkins build jobs with pre-release tokens might need work. Although with the develop job taught somehow to use alpha/beta/rc intelligently maybe only one job will handle all that - could work. Experimental builds have been a separate build job using a different branch in the past, which could be enough.
- Version 0.x.y is initial development and not expected to fully adhere to the semver standards for when to increment major/minor/patch. I figure the MoSCoW stages and the implementers opinion for what's a change substantial enough to increment "minor". Patch level again really could just be the Jenkins job/build number, but then I'm violating semver again and screwing up the definition of the pre-release token.
- Version 1.x.y is for when something is stable enough to follow the semver conventions exactly so other developers and modules can rely on the version number alone to calculate dependencies and plan around API changes. Possibly we could change from using Jenkins build numbers at the patch scope to using semver properly - although really a patch is any change, which takes a Jenkins build ...
One tricky bit is that if we involve the Jenkins job build numbers we must only use it from one job per repo, and keep master/develop branches in sync. Otherwise a Terasology unstable (pre-release) build from develop would speed ahead in patch number vs a stable build from the master. Would have to ignore the master build number and simply take off the pre-release token when pushing changes forward from develop to master. Say Jenkins develop build 123 would create 0.5.123-alpha; push to master and that would become 0.5.123 (but then would lose the informative "alpha" status ... wah, this is hard)
Edit: I'm thinking more about how semver really wants the alpha/beta pre-release stuff to happen betweeen natural releases (1.0.1-alpha, 1.0.1-beta, then 1.0.1 and afterwards work begins on 1.0.2-alpha) not alongside natural releases (1.0.1-alpha, 1.0.2-alpha, then 1.0.2 - no formal 1.0.1 release) But the magic 0.y.x period really is entirely "pre-release", so I wonder if it what I'm outlining above makes sense, then at 1.y.x you swap to alpha/beta/rc being entirely between natural releases.
Organizing Teams
A final brief note here on teams, or the lack of coherent teams beyond just badging people left and right.
A final brief note here on teams, or the lack of coherent teams beyond just badging people left and right.
- Focus heavily on Game Modes (L&S) as the biggest sub-divisions for teams rather than function (Art, Architecture, Design, etc)
- Make project-wide roles less overwhelming by focusing on helping game mode teams rather than all the things at once
- Use GitHub milestones and issues to organize primarily Game Mode development, like the current example (1, 2) with L&S
- Project wide (some existing, some new)
- begla as overall Lead Dev and 3D wizard, able to help overall on various topics
- Me doing the "juggle all the things" thing
- Immortius as Lead Architect to also be able to provide global guidance
- Skaldarnar in an overall Design role of some sort (project state type threads and similar global stuff)
- mkalb as Release Manager. Sort of close to what Skaldarnar has been doing, but more infrastructure / version specific
- UberWaffe as overall Analyst of some sort with magic MoSCoW fairy dust to sprinkle over all the threads of the land
- Light & Shadow
- SuperSnark for Game Designer to add extra detail where needed
- glasz for Art style to keep it consistent within the game mode
- Steam Fortress (in short focused on DF features)
- Brokenshakles for Game Designer
Ooookay. Yeah that's still long. Sorry! Thoughts? Aiming to post one of these threads per day I'm off, hah!
