nogalpaulina/bwa-u4-feature-request

bwa-u4-feature-request's Issues

Project Review

Rubric Score

Criteria 1: Objective Section

• Score Level: 4/4
• Comment(s): Your objective section is pretty and I especially like that it is short and to the point! I would like to recommend however, that you consider writing the objective more from the user's perspective. This ensures that the document's readers (which are typically project stakeholders, business leaders, and engineers) all walk away with a baseline common understanding of the feature and what it means for the user. Otherwise you could end up with varying ideas of what the feature really is, what it means for the business, and how it might be implemented.

As an example, here is a more user centric version that I came up with:

Request users to select a different name if a playlist with that name already exists so that user experience can be increased and user confusion decreased.

Criteria 2: Background Section

• Score Level: 4/4
• Comment(s): Your background section does a good job fleshing out how the feature would work and why it is important. Though there is no way to obtain this type of data on our Jammming project, this section would be a good place to provide something more concrete for why the feature is important. For example, you could indicate that X number of related support requests would be eliminated or site some customer feedback that they don't enjoy duplicates. The point is that in a real life feature request doc, you typically want to provide some actual evidence to quantify the importance.

Criteria 3: Technical Design Section

• Score Level: 3/4
• Comment(s): Similarly, your technical design section is pretty good, but I felt like it was missing some key information. For example, you mentioned adding a new function in Spotify.js to get the user's existing playlists, but I think it would also be good to site the actual Spotify API that this new function would be using (e.g. perhaps GET /v1/me/playlists or GET /v1/users/{user_id}/playlists. This way its clear to the future developers what exactly you had in mind.

Also, there wasn't any mention of which App components need to be modified in order to actually call the above mentioned function. For example, you would most likely update your App component's savePlaylist method to perform the check upon save. There would probably need to be a new prop passed somewhere to indicate the result of the check, or something like that.

You also did not mention where you would store your existingPlaylists array (directly in Spotify.js, in an app component, somewhere else...) or discuss how you might keep the array updated as new playlists are added.

Criteria 4: Caveats Section

• Score Level: 2/4
• Comment(s): Like most everything in software engineering, there is typically always more than one solution to a problem that each have their own set of trade-offs. The Caveats section is where you would mention some alternate solutions and explain why they were ultimately not the one that you went with. For example, another solution that I can think of would be to call the Spotify playlist API every single time the user tries to save a playlist in the app. The trade-offs here is that saving will take a bit longer to complete however you are guaranteed to be checking against the latest set of playlists for the user. So you would want to mention these types of alternative approaches and argue why they were not selected.

Overall Score: 13/16

Overall I thought you did a fantastic job on this project! Pretty much all sections were nicely done and hopefully my feedback on your Technical Design and Caveats section shed more light on how to deal with these aspects in the future. I was also happy to see that you selected a unique feature requests instead of using the few examples provided in the project spec. It shows you actually thought about how to further improve the Jammming app!

Keep up the great work!