Design Docs

[dsuh93]

Hey Richard! Design Docs are looking good but could be better! Here's a checklist that you can follow as well as some comments that I would like you to consider with each design doc. Let me know if you have any questions

Wiki Page Home

​

• [X] Is the first page you see upon entering the wiki
• [X] Contains a welcome message
• [X] Contains a link/placeholder for a link to the live page
• [X] All links in the right sidebar should contain each wiki page and link to the correct page
• [X] Correctly formatted
  • [X] each wiki page is listed in bullet points
  • [X] all links route the correct page ​

    Comments

    ​

    MVP List

    ​

• [X] Should have 7 MVPs.
  • [X] 3 of those are User Auth, Heroku, and Production README.
  • [X] The other 4 are from the MVP List or ones clarified with the PM
• [X] Contains a description sentence of the app
• [ ] Includes two to three detailed bullets on functionality and presentation of feature
• [ ] At least one CRUD feature, which states what CRUD operations are planned (creation, reading, updating, deletion)
• [ ] Estimates how long it will take the code each MVP
• [ ] Correctly formatted
  • [ ] MVPs are listed in an ordered list
  • [X] Each MVP is broken down into bullet points ​

    Comments

• [ ] Add details for each MVP, look at Sipper wiki for example
  • details should let us know what users are able to do or what users will see (presentational details and functionalities accessible by each MVP)
  • i.e. Users are able to upload photos while logged in
  • i.e. Users can unfollow other users
  • i.e. Users can personalize their Home Feed
• [ ] Uploads and Likes should be separate MVPs, I would move Likes (and comments) to a bonus MVP, and have Uploads be completed in 2 days, and should include CRUD details in the bullet points

Database Schema

​

• [x] Contains correct datatypes
• [x] Contains appropriate constraints/details
  • [x] primary key
  • [x] not null
  • [x] unique
  • [x] indexed
  • [x] foreign key
• [ ] Contains bullet points after the table that state which foreign keys will reference to which table, or references to the associations which will be made
  • [ ] foreign key and table name are lowercased, snake_cased and back_ticked
• [ ] Correctly formatted
  • [x] schema is written in a table format
  • [ ] the table's name are lowercased, snake_cased and back_ticked
  • [x] the table header column names are bolded
  • [x] columns names are lowercased and snaked_cased and back_ticked ​

    Comments

• [ ] Missing a photos table in your db, this should hold individual details on each photo (though not the actual photo itself if you plan on implementing AWS)
• [ ] add bullet points for indexes under Users and Comments, make sure to follow markdown formatting in Sipper wiki example
• [ ] missing references bullets for LIkes, Comments, and Follows
• [ ] reformat table names

Backend Routes

​

• [ ] Contains the following sections: HTML, API Endpoints(Backend)
• [ ] Each route has a description
• [x] API Endpoint routes contains wildcard variables written in snake_case
• [ ] Routes does not contain superfluous routes
• [ ] Have API routes that will allow the front end to get all info it needs and does not have unneeded routes:
  • example: probably don't need a GET likes api endpoint because that info comes through the photo show ​

    Comments

• [ ] reformat so that api routes are under API endpoints section, and only the html route is under the HTML section
• [ ] missing descriptions for routes
• [ ] should add routes to Photos regarding receiving info for a single photo (show page) and editing a photo pages details
• [ ] add edit route for a photos table in the backend

[rzleu]

Thanks David!

I appreciate all the details you put into reviewing my design docs.

On Tue, Aug 31, 2021 at 3:10 PM dsuh93 @.***> wrote:

Hey Richard! Design Docs are looking good but could be better! Here's a checklist that you can follow as well as some comments that I would like you to consider with each design doc. Let me know if you have any questions Wiki Page Home

​

• Is the first page you see upon entering the wiki
• Contains a welcome message
• Contains a link/placeholder for a link to the live page
• All links in the right sidebar should contain each wiki page and link to the correct page
• Correctly formatted
  • each wiki page is listed in bullet points
  • all links route the correct page ​

Comments

​ MVP List

​

• Should have 7 MVPs.
  • 3 of those are User Auth, Heroku, and Production README.
  • The other 4 are from the MVP List or ones clarified with the PM
• Contains a description sentence of the app
• Includes two to three detailed bullets on functionality and presentation of feature
• At least one CRUD feature, which states what CRUD operations are planned (creation, reading, updating, deletion)
• Estimates how long it will take the code each MVP
• Correctly formatted
  • MVPs are listed in an ordered list
  • Each MVP is broken down into bullet points ​

Comments

• Add details for each MVP, look at Sipper wiki for example
  • details should let us know what users are able to do or what users will see (presentational details and functionalities accessible by each MVP)
  • i.e. Users are able to upload photos while logged in
  • i.e. Users can unfollow other users
  • i.e. Users can personalize their Home Feed
• Uploads and Likes should be separate MVPs, I would move Likes (and comments) to a bonus MVP, and have Uploads be completed in 2 days, and should include CRUD details in the bullet points

Database Schema

​

• Contains correct datatypes
• Contains appropriate constraints/details
  • primary key
  • not null
  • unique
  • indexed
  • foreign key
• Contains bullet points after the table that state which foreign keys will reference to which table, or references to the associations which will be made
  • foreign key and table name are lowercased, snake_cased and back_ticked
• Correctly formatted
  • schema is written in a table format
  • the table's name are lowercased, snake_cased and back_ticked
  • the table header column names are bolded
  • columns names are lowercased and snaked_cased and back_ticked ​

Comments

• Missing a photos table in your db, this should hold individual details on each photo (though not the actual photo itself if you plan on implementing AWS)
• add bullet points for indexes under Users and Comments, make sure to follow markdown formatting in Sipper wiki example
• missing references bullets for LIkes, Comments, and Follows
• reformat table names

Backend Routes

​

• Contains the following sections: HTML, API Endpoints(Backend)
• Each route has a description
• API Endpoint routes contains wildcard variables written in snake_case
• Routes does not contain superfluous routes
• Have API routes that will allow the front end to get all info it needs and does not have unneeded routes:
  • example: probably don't need a GET likes api endpoint because that info comes through the photo show ​

Comments

• reformat so that api routes are under API endpoints section, and only the html route is under the HTML section
• missing descriptions for routes
• should add routes to Photos regarding receiving info for a single photo (show page) and editing a photo pages details
• add edit route for a photos table in the backend

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rzleu/16-bites/issues/1, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOVWEWNKXP4ADWJSIWBDLETT7VHNTANCNFSM5DFCRA2Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.