Narrowing the Scope for First Steps

[timmyichen]

I'd like to propose a change in how we plan for, develop, and roll out features.

Right now it seems to be a very top-down planning-heavy approach, where we flesh out the entire database schema before moving forward with any development. I would like to propose a more bottom-up approach where we design things to be extensible, but build them in their basic form first.

Proposal

In order of priority, here are the high level goals of what we should work on:

• Allow users to sign up / log in / log out
• Allow users to create Chapters
• Allow users to create Events
• Allow users to RSVP for Events

Breaking these goals into possible PRs might look something like:

• Add models for Chapters, Users, and Events
• Create login/signup flow for Users
• Create API routes for creating, updating, and deleting Chapters
• Create API routes for creating, updating, and deleting Events
• Frontend for CRUD-ing Chapters'
• Frontend for a Chapter page / view
• Frontend for CRUD-ing Events for a chapter
• Add models for RSVPs
• Create API routes for RSVP-ing and un-RSVP-ing for Events
• Frontend for managing RSVPing

Please feel free to leave comments/thoughts/suggestions here.

[timmyichen]

cc @QuincyLarson

[vkWeb]

cc @nik-john

[Zeko369]

@freeCodeCamp/chapter-moderators

[ceciliaconsta3]

Making note to discuss this in the next team meeting

[allella]

I'm not sure I see where this narrows the MVP's scope, but the point about organizing around top-down and bottom-up thinking is well taken. If I were implementing this stuff I'd surely want to break it down into a technical list, even if only for myself.

Disclaimer: I have very little experience with User Stories and Agile.

User stories lend themselves to the end-case / front-end / top-down way of thinking based on user interactions. That's clearly by design and it doesn't make anything wrong about the pattern. However, it assumes that everyone will figure out what they need to do based on the user stories without breaking it down into more concrete tasks.

Surely someone has experience on how to work with User Stories while keeping both top-down and bottom-up thinkers satisfied.

Just spit-balling ideas here, can you have a mix of of user stories (serving designers, front-end, UX and secondarily the back-end) and then more focused technical issues (serving back-end devs), or does that get messy?

Or, what about adding the more granular, technical task list as a checkbox list under the associated User Stories?

[timmyichen]

I wouldn't say that it narrows the scope of the MVP as much as it narrows the scope of what we want to get done in the next two weeks. e.g. there was some area of contention in #162 around tags, which are indeed an MVP feature, but not worth implementing until the base models are implemented. Doing the basics first allows for faster development as the features like tags, permissions, etc can all be done independently and concurrently.

I don't have much experience with User Stories / Agile either 🙃 but I can see why it would be difficult for someone to figure out what would make a good PR for the codebase in its current form.

In the list of potential PRs above, each of those can be split up into tasks for designers / front-end / back-end / UX / etc. Would love to also hear more from anyone with more experience in these processes as I have little.

[allella]

Another spitball ideas for consideration, if nobody has a better suggestion, would be to stub out some of the most immediate items under Tim's "Breaking these goals into possible PRs might look something like:" list into PRs and have folks contribute on those PRs. That assumes it doesn't create a problem with keeping in sync with master or creating a merge hell.

Though, if we're going to placehold these tasks these it begs the question why we wouldn't just create an issue for them and tag them differently to distinguish vs user stories.

[QuincyLarson]

@timmyichen Rather than get rid of our existing user stories, you could go into their descriptions and break them down into more concrete steps and create a checklist.

Slicing and dicing the work further may make us feel more productive, but in the end, someone has to sit down and bang out the code - regardless of how it's classified or what type of task it is.

Ultimately, we need API endpoints first before we'll be able to build the functionality on the front end, which is why I encourage us to focus on that first.

[QuincyLarson]

Hi everyone, I've thought a bit more about what @timmyichen said here. He wasn't able to make today's meeting, but we were able to discuss this.

I agree that we need to "break things down into smaller bits" and make the work at hand clearer.

Here is a general flow of what needs to be done:

[Tool work] -> [API coding] -> [UI coding] -> [Testing] -> [Release]
[UI design] ------------------------^                         ^
[Documentation] ----------------------------------------------|

Right now, @Zeko369 is finishing the tool work, getting the ORM working and a few other tasks.

Then we will be able to start the process of coding the API in earnest.

The UI coding depends on the API coding, so we will wait on that. But in the meantime, we can use those UI GitHub issue threads for housing designs. @madaleneaza-design, @vkWeb, and others contributors can help design the UI and what the interactions will look like for end users. Then, once the API coding is done, contributors can use these designs (Figma mockups) as a reference for building the UI. They can pull requests against those issues to close them with functioning UI code.

And documentation - which is just as important, can be completely decoupled. Ideally, documentation informs design decisions and how the API itself will be designed. But in practice, waiting for all the documentation to be done first would cause even more delays. We should instead start coding and iron things out as we iterate.

Once all these parts come together, we can test it and ship our MVP.

To this end, I've created new, more granular issues around our user stories. Here's a screenshot of our Project board:

@nik-john had some great feedback on this during the meeting, and explained how his team handled large projects with sagas, user stories, than individual tasks within those by using a system of Git branches and further branches off of those. We may be able to incorporate something like this down the road, but I think it's too complicated for our MVP. So instead, I think by categorizing all these tasks as Tooling, API, UI, Design, or Documentation, and visualizing what needs to be done in what order, we can get a lot of the benefit without all the complexity. Again, the chart:

[Tool work] -> [API coding] -> [UI coding] -> [Testing] -> [Release]
[UI design] ------------------------^                         ^
[Documentation] ----------------------------------------------|

I'll keep this GitHub issue open for now so we can further discuss this and any questions / suggestions you all have regarding this approach.

[allella]

@timmyichen we talked a good deal about this at today's meeting.

You said the Project board was helpful to visual progress. There's a link to the project board on the README under the User Stories section.

We also talked about using labels as a way to help people who want to organize the issue in a different context. For example, a "blocked" label and labels for "user", "organizer", "admin".

Also, Quincy broke the issues up into more granular chunks for UI, API, and Docs after the previous meeting.

Are there additional ways we should look to organize or help narrowing the scope?

[timmyichen]

I think the Project board is great to start, and the addition of the labels is definitely helpful - this issue can probably be closed. Thanks for addressing my concerns!

[allella]

Also, the conclusion of much conversation about this topic from today's meeting was to get issues un-stuck by having anyone who's interested post their ideas, thoughts, questions, and such on the specific issues.

We have a mix of people who think of things in different ways, but it doesn't really matter how the information is conveyed, as long as it's put out in the open in some format (text, mockup, hand-drawn, user flow chart, smoke signal).

More specifically, from the meeting notes:

• It was suggested we continue thinking through the user flows, empathize with the user, and “get something down on paper” and share something on the related Github issue(s).
• Sharing our ideas, mockups, drawings, or anything that inspires more conversations is more immediately valuable than codifying process and tools. Though, everyone is welcome to use the tools that allow them to get their ideas out in the open.
• If / as tools or processes prove to be helpful then we’ll adopt the ones that work for this project.
• Examples of recent conversations which have helped to quickly move along UI issues and provide a basic for more detail-focused mockups:
  • #107 - decisions were made on missing fields in the schema and how to account for event vs chapter notifications
  • #274 - productive conversation about which UI elements to use for subscribing or unsubscribing

[allella]

Closing, per Timmy.