You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The first stage of any new feature is conception. This is where an idea is though of or proposed. This idea should then be catalogued on the Issues tab of the repo. Provide as much clarity as possible not only for your late self but also to aid others through the development process. Tags should be added to the issue where appropriate.
🔬 Research - 01
The second stage is research. Whether it's as simple as a single google search or spending hours scrolling on Minecraft forums, the research stage is vital at finding out if an idea is even possible and if it is just how the best way is to do it. Where possible this stage should be documented on the issue and any links should be provided where possible to ensure appropriate credit is given. In some cases where something is completely new this stage may work in parallel with 02 and can be referenced as such in the next stage.
🚧 Prototype - 02
The next stage is the fun part: prototyping. No code involved simply create a working version on your device to reference throughout development. Documenting the prototype process is vital for the next stage and should be done in as much detail as possible on the issue page. Where possible you should also upload any working files for safekeeping and reference.
📅 Planning - 03
Now for planning! Whether it's an old school flow diagram, pseudocode or a simple list, planning is key to make writing and integration a breeze. Again this should be documented where possible attached to the issue.
✍️ Writing - 04
Finally time to write! It's as simple as it sounds open that editor and start coding! Create a new repo branch for the issue your working on and ensure this is synced with GitHub desktop. Any major milestones you reach in development can be documented by a commit to your branch. The title should specify the version number and you can increment 0.0.1 from the last version! (Please note this sequential system is being abandoned soon in favour of MAJOR.MINOR.PATCH) The description while brief should be descriptive.
⚠️ Test - 05
Now for the boring part... TEST TEST TEST. Ironing out as many bugs now will make your life so much easier in the future. A full guide to testing Totems+ can be found here (comingsoontm)
🧩 Integration - 06
Now it's time to ensure your feature cooperates with all of Totems+. This often involves outlining new functions and handling data transfer between feature files.
⚠️ Test - 07
See 05. Also now check your feature works with other Totems+ features, even those it may be mutually exclusive too!
💅 Polish - 08
Time to polish it all off, add code comments and make it all look pretty. Your good looking code is valued and appreciated!
⚠️ Test - 09
See 05. It's also at this point you should consider getting your code peer reviewed if possible to ensure it will work on all systems
📕 Merge & Close - 10
That's it! Make sure everything is committed and create a pull request. Make sure you link it to the issue so that is closes with the pull request. If your ready to release a new version you check our release workflow post here (comingsoontm).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
💡 Conception - 00
The first stage of any new feature is conception. This is where an idea is though of or proposed. This idea should then be catalogued on the Issues tab of the repo. Provide as much clarity as possible not only for your late self but also to aid others through the development process. Tags should be added to the issue where appropriate.
🔬 Research - 01
The second stage is research. Whether it's as simple as a single google search or spending hours scrolling on Minecraft forums, the research stage is vital at finding out if an idea is even possible and if it is just how the best way is to do it. Where possible this stage should be documented on the issue and any links should be provided where possible to ensure appropriate credit is given. In some cases where something is completely new this stage may work in parallel with 02 and can be referenced as such in the next stage.
🚧 Prototype - 02
The next stage is the fun part: prototyping. No code involved simply create a working version on your device to reference throughout development. Documenting the prototype process is vital for the next stage and should be done in as much detail as possible on the issue page. Where possible you should also upload any working files for safekeeping and reference.
📅 Planning - 03
Now for planning! Whether it's an old school flow diagram, pseudocode or a simple list, planning is key to make writing and integration a breeze. Again this should be documented where possible attached to the issue.
✍️ Writing - 04
Finally time to write! It's as simple as it sounds open that editor and start coding! Create a new repo branch for the issue your working on and ensure this is synced with GitHub desktop. Any major milestones you reach in development can be documented by a commit to your branch. The title should specify the version number and you can increment 0.0.1 from the last version! (Please note this sequential system is being abandoned soon in favour of MAJOR.MINOR.PATCH) The description while brief should be descriptive.
Now for the boring part... TEST TEST TEST. Ironing out as many bugs now will make your life so much easier in the future. A full guide to testing Totems+ can be found here (comingsoontm)
🧩 Integration - 06
Now it's time to ensure your feature cooperates with all of Totems+. This often involves outlining new functions and handling data transfer between feature files.
See 05. Also now check your feature works with other Totems+ features, even those it may be mutually exclusive too!
💅 Polish - 08
Time to polish it all off, add code comments and make it all look pretty. Your good looking code is valued and appreciated!
See 05. It's also at this point you should consider getting your code peer reviewed if possible to ensure it will work on all systems
📕 Merge & Close - 10
That's it! Make sure everything is committed and create a pull request. Make sure you link it to the issue so that is closes with the pull request. If your ready to release a new version you check our release workflow post here (comingsoontm).
This post is currently on v1.0
updates to come :)
Beta Was this translation helpful? Give feedback.
All reactions