Please describe or delete if no longer necessary.

From https://github.com/phetsims/special-ops/issues/185, @samreid mentioned that this may be a good time to do this. Here is the checklist:

Delete Repo Checklist

Before using this checklist:

Decide whether the repo is being (a) deleted (b) archived or (c) removed from active-repos.

• A repo should be deleted if
  • it is clutter
  • it will never be used again
  • there is no valuable information in the GitHub issues
  • it is not referenced by any SHA in any published simulation
• A repo should be archived if
  • we don't want to continue development on the repo, but it needs to stay for reference or because its SHAs are used.
  • We want a paper trail for issues/decisions/commits made in the repo.
  • you may also want to make it private, if it should not be used for reference by 3rd parties
• A repo should be removed from active-repos if
  • We cannot maintain it at the moment, but we expect to bring it back into maintenance in the future.

Do not remove repos that:

• Are listed as dependencies of any published simulation.
• Would prevent checking out old versions of sims (do not mess with the bisection).
• Contain otherwise useful information that is linked to

Deleting or Archiving Steps

• Before deleting something, it should be approved for deletion at a dev meeting
• If not confident about some of the above questions/advice, bring it to a dev meeting
• Create a delete/archive repo github issue in special-ops.
• Inform the dev team to delete their local copy (perhaps put a checklist of developers in the github issue)
• If issues crop up they should be documented in the associated github issue for the dev responsible for deletion
• The repo should be removed from active-repos, ideally a few minutes before archiving/deleting (so automated processes do not try to pull it)
• In general, removing the repo should not break much, if empty rows in CT are a concern,restart CT
• If archiving, update the repo's README.md file to indicate why it is archived

We should explicitly state whether something needs to be done to delete the directory from aqua, build-server, and phettest, or whether these directories get automatically deleted, or just hang around forever with no consequences

To help work on eliminating TTypes https://github.com/phetsims/phet-io/issues/1112, we are going to use blast as a guinea pig

How to Instrument a PhET Simulation for PhET-iO

Overview of instrumentation steps:

• Copy this checklist to the issue description (top issue comment) for tracking. Make sure to use a permanent link like /blob/<SHA>/ so that the specific guide you used is preserved.
• Understand the goal
• Code review
• Use Property instead of PropertySet
• Import Tandem to main.js
• Create root tandem
• Pass tandems to sim screens
• Pass tandems to model and view
• Pass tandems to all constructors defined by the simulation
  • See also Testing while adding Tandem instances. Test with ?phetioValidateTandems=false since some common code-components don't yet have tandems.
• Pass tandem instances to common code components
  • See also Testing while adding Tandem instances.
• Create static tandems where appropriate.
• Replace types with tandemized equivalents
• Instrument any uninstrumented common-code components used by the sim
• Instrument new component types defined by the sim
• Add simulation specific support
• Support dynamic state
• Make sure Joist dt values are used instead of Date.now() or other Date functions. This is necessary for reproducible playback via input events.
• Are random numbers using phet.joist.random, and all doing so after modules are declared (non-statically)? For instance, the following methods (and perhaps others) should not be used: Math.random, _.shuffle, _.sample, _.random
• undefined values cannot be saved by phet-io, sims should be written to use null instead
• Verify that the simulation works in all of the phet-io wrappers
• Add this sim to the list of phet-io sims in chipper/data/test-phetio
• Build with grunt --brand=phet-io and test the built version by launching build/wrappers/index and testing all the links
• Set up a task to have the newly instrumented sim tested by the QA team
• Update these instructions if you find them to be incomplete, inconsistent or incorrect
• After publishing, add your instrumented simulation to the spreadsheet here: https://docs.google.com/spreadsheets/d/1pU9izdNQkd9vr8TvLAfXe_v68yh-7potH-y712FBPr8/edit#gid=0

At today's developer meeting, I recommended deleting blast, and the proposal was met with approval. I'll delete it shortly. It was never a dependency for another project, so it should be safe to delete.

Noticed while adding namespace.

This sims has 2 screens, so should have 2 subdirectories for those screens. The directory structure currently looks like this:

Noticed while adding namespace.

This sims has 2 screens, so should have 2 subdirectories for those screens. The directory structure currently looks like this:

Identified by print-branches.sh. Please describe.

Looks like initial commit was made by @samreid.

There's not a lot going on in this sim. But there are some bits that should be documented, like:

• The purpose for each screen
• What and why for ItemModel.step (apparently something to do with memory profiling, according to the commit message)
• What and why for BlastModel.step (apparently an animating particle/rectangle, according to the commit message. but why?)

Seems like it would have been pretty easy to do all of the above when the code was created.