Open conoramurphy-zz opened 5 years ago
First Suggestions here
https://share.goabstract.com/b0212c5e-d6a6-4c86-bf85-085155265802
So, a couple of points:
So I'm proposing a simpler version.
There are theoretically 4 stages to a volunteer path on CoderDojo
My proposal is... treat them separately. Create issues about doing a small messaging change to support 1. A larger piece like a small pathway to support 2. and for 4 suggest adding in a footnote about becoming a co-champion.
Pros Smaller focused pieces of content for each of them that target the specific problem we've noted. Less design work.
Cons Less of a redesign and no major improvement except for (2). Not a major con to be honest!
https://share.goabstract.com/b0212c5e-d6a6-4c86-bf85-085155265802
Three stages are now included in this ticket.
First state : New volunteer no club or applications to join. Tweaked message in above screens. Second state : Volunteer with open applications, no club. Second screen above, new card with suggested next steps and some mild time fillers. Third state : Volunteer with both open applications, and a club, and it's the first 3 months. This is to cover a case where someone applied for several clubs. Third screen in abstract. Basically they should still be shown most of the second state date until 3 months pass and then we can assume they understand the process.
Notes:
First state:
Notes: there is a strange difference between waiting a few days for a requests, and displaying for 3 months a guide. I understand they serve a different goal, but you'll have fresher data from our list of projects for example than any links in the current projects.rpf platform (maybe the new homepage ?). As well, the safeguarding module is a 10 minutes action that is going to be there.. for 3 months. You're unlikely to come back to it because of its simplicity (which is not the case of the guide, for example). That's why overall, I'm pushing for a side-list of links for already-in mentors, it's because those resources are good as references, but aren't useful for 3 months or are already displayed in a better manner next to it (projects). If this becomes an accepted solution, I would recommend changing the titles to something more neutral, such as "Our projects website" or "Discover more projects".
For not defined how we identify that case, we don't know he wants to volunteer without requesting it in the first place
Should have clarified that should generally just be the default message for all users that have 0 actions done and haven't created a lead or anything.
Fair enough on the 3 months. It's always an arbitrary choice. It can be 30 days on the list of actions part. The 3 months is more for the pending applications part so we can split the pending and the list. If for state 3 you want to push the list into the side no problem, I will survive (but genuinely no problem there, the first two states by far the most important for this ticket).
So, the way forward can be seen in 2 ways: 1) migrate endpoints to v3 for join_requests, stick to the current db structure 2) migrate endpoints to v3 for join_requests, change the db structure to reflect its nature
The second point means migrating the join_requests from the user profile and the user db to the cd_usersdojos (club membership) table from the dojo db. However, this impact retro-compatibility in 2 ways:
At some point we are going to have to pay off this tech debt and start making these changes to db schema/ re-organising of services. Do you have any estimates for how long each solution would take? You say the length of solution is the same, but then that one is way more work so I'm a little confused.
If we go with the efficient solution and leave the db as it is what is the outcome, the services are harder to reason about because the same or very similar functionality is in different services?
If we don't move things now, under what circumstances to we ever take the decision to move something.
Sorry, by "the same", I meant to say that the length of doing 2) is as long as twice 1), due to the dependencies of the front-end to that API. That would force us to deprecate that part of the v2 API since the back-end would be different; and hence requiring either a rework of the front by either using the new API despite being in the ng1 version; or a total rework of the page in vueJs.
If we go with the efficient solution (1), it means the data is not part of the db I would expect to be in (the dojo db) and hence the logic will belong to a service I would not expect to be in (in this scenario, the logic will need to be in the user-service instead of the expected club-service).
As well, in solution 1) the process would not be replicated, but will coexist with the v2 version as they rely on the same data structure and db. That means that some interfaces will make use of the v3 API (request to join as, booking process which makes people join as parent/attendee), and others will use the v2 (champion's display for managing requests likely).
If we don't move now due to the size of the task, I would ensure that every interfaces making use of that entity have been rewritten. At that point, only the first bullet point (selecting from the cd_usersdojos table..
) will be the issue, which isn't that big (probably 1 day writing, 1 day testing) by itself.
The reason for solution 1) are to avoid trying to solve 2 very different and large issues at a time (Seneca deprecation AND schema being a bit all over the place) while solution 2) is about getting it right (once and for all until something else happens) whatever the cost.
For 2nd state, should we filter the requests to join created after a certain date? I'd like to avoid a weird experience with requests to join which are 3 years old. @conoramurphy
The "3 months" hiding point should cover that. This is only relevant for the first 3 months.
It can be 30 days on the list of actions part. The 3 months is more for the pending applications part so we can split the pending and the list.
Fair point, sorry.
Np, a lot of content in this thread.
Business Goal
For any new volunteer (first 3 months), make sure we have clear next steps on the dashboard. We hope to see increased engagement and increased retention. https://docs.google.com/document/d/1xVZSRaiZ_gsvaVWwFsQkFLTNYiRvu1drD31XULofHeo/edit#
Task
Tweak messaging and the "This is the most important things" section on the dashboard for new volunteer experiences.