Problem

Given that/doc is now the root folder/index, a lot of the indexing that used to live on theusers index page is now on thedoc/index and it's a little easier to find things when the code structure matches the indexing. Also currently it's a little hard to define what we mean by user guide and scoping the contents of the folder can help in defining the purpose.

Suggested improvement

• /users/project ->/doc/project
• /users/installing->doc/installing
• /users/{generate_credits, github_stats, *_whats_new, release_notes*} ->/doc/release
• `/getting_started/* -> quickstart guide
• /users/users_explain/* ->/users

Consensus

As discussed on the call, the rough consensus is this organization makes sense but should be done in stages, roughly one folder at a time. Largest concern was getting all theredirects correct and making sure that any links and instructions related to those docs are updated as needed. The stages are:

• move the/project folder up ->Moved /users/project to /doc/project #27560
• move the/installing folder up -> (might be a good chance to change the name to install?)Move doc/users/installing/ to doc/install/ #27747
• move the release related folders and docs {generate_credits, github_stats,_whats_new, release_notes} into a folder and up one level
• merge the contents inusers/getting_started into thegallery/users_explain/quickstart guide and remove thegetting_started folder
• removedoc/users and renamegallery/users_explain to users

Motivation

• currently/users/index/ is scoped tousers_explain +getting_started, this would be matching structure to stated structure, in turn making it easier to find where a doc is to change it
  • also means we can remove the symlink, which currently trips folks up when trying to edit documents under /user
• the contents under/project are I think version independent (though we may want to keep the versioning on the site b/c the historicity is also important) but also for the most part should not be changed w/o consensus/streering-council sign off and it's a little easier to communicate that if it's not lumped with other user docs
• I'm half/half on/doc/install b/c I understand why it would be inside a users guide but we also write those documents as a more general installation guide/reference for both
• there are a lot of files related to the release process and unlike/api/changes it's not clear why they are here.