[Draft Epic]: PlaceCal v1.0 MVP

[kimadactyl]

Overview

A ticket to track our status releasing PlaceCal v1.0. This work will be completed across multiple milestones and tickets and this aims to keep an overview of the project. This ticket is to focus on the absolute have to haves -- let's focus on making what we have right now work reliably and well.

Overall this core funcionality is all reviewing the basic create, read, update and delete commands for our 3 current user groups and making sure they're all watertight and nice to use (citizens, partners, and organisers)

This kind of ticket might be a terrible idea but I think i prefer to keep this thinking in the repo and not notion.

Tech Debt

• Update to Rails 7 (Upgrade to Rails 7 #1110)
• Update to Ruby 3.x (Ruby v2 nearing EOL (Dec 2023) #1786)
• Host fonts ourselves  #2248
• Check we are not including gems we don't actually use List and review gems used #2159
• Security sweep for leaky data ([Bug]: Remove random json emissions #2065 & Verify that only public data is exposed on the open API. #2097)
• README.md easily gets you to a state a member of staff can develop from #2088
• Migrate mountain_view to view_component #2270
• [Epic] Remove old jQuery-based functionality from the code base #2600
• No broken or incorrect links in interface anywhere
• Resolve any errors in Appsignal
• Resolve slow running processes reported by Appsignal
• Make sure all open Renovate tickets are merging
• Rewrite test suite
• Review and complete calendar importer functionality - esp when it comes to event locations

Citizens

• Improve our open graph previews #2491
• Citizens can filter, sort and search for partners in their area or by their interest (i think we should rip out the jquery stuff there now in favour of hotwire stuff)
• Citizens can filter, sort and search for events in their area or by their interest (ditto)
• You can find out who to contact if things go wrong
• Data is well formed for ld+json etc
  • Improve PlaceCal markup for SEO & data Access #816
• Accessibility sweep on frontend #2160
• Accessibility sweep for admins (focus on partners) - if we can reach AA on the frontend that'll be a big sell for some audiences #2161

Partners

• It is clear what happens with your data once added (e.g. Calendar admin page does not specify if contact info is public or private #2069)
• Have a reasonable onboarding experience - it would be nice to have some kind of like profile completeness thingy if thats not totally naff i think. its a very big intimidating form.
• Partner admins have appropriate access rights (Make a ticket for partner admin access rights)
• We get regular (regular can mean bimonthly, just you know, at all) confirmation that listings are still up to date (i think this is the email notifs MVP)
• Calendar importer gets some love and gives instant / live load results - atm you need to toggle between about 4 screens and wait ages to find out if it worked

Organisers / Commissioners

For now these are the same thing - lets make both work to a minimum standard first, and look at commissioner-specific rights later on.

• Organisers have appropriate access rights
  • Audit and fix Partnership Admin permissions #2063
  • PlaceCal Norwich's Organiser should have the proper set of permissions #2062
• Organisers can do some customisation / personalisation of their site pages without our input
• Organisers can do filtering and sorting on partners on key fields for e.g. seeing ones where there's no events, no category, thngs in one given ward (e.g. rip out datatables) - https://github.com/geeksforsocialchange/PlaceCal/milestone/25

Bonus features

Low hanging fruit that could be seen as part of getting wider adoption of the idea as a whole but are deffo not 100% needed technically. I guess you can think of this as ecosystem stuff - like if we are selling an ecosystem then we need at least a minimal thing to point at about what the ecosystem looks like to make our USP clearer that we're not just about selling another app. It helps these map on to our user groups too!

• Provide code for a basic embed for partners to use on their website - i think this would be a huge sell to get them on board
• Create a trans dim boilerplate - ditto for organisers
• User-customisable ical feed - the least needed but also this opens up a lot of customisability for people using it (and would make this rationale logically consistent if we had an export option for each of organisers, partners, citizens)

[ivan-kocienski-gfsc]

Looks good! I agree this is more helpful in github as that is where the code is.

Just a couple of small points

• Upgrade to ruby 3.x
• Are you calling Citizens users who are visiting the public site? (we already use that term in the admin side of things to designate someone who is not root or not and editor)

The rest seems okay. Guess we'll be working through christmas at this rate ;)

[kimadactyl]

Yep sounds good to 3.0, we should be up to date with latest everything right.

And yes to citizens. If confusing can change. But my idea was to never refer to an abstract user but rather you know, an idea of who the person actually is, in this case a resident of somewhere or a fan of an interest.

And yeah dw i think this will prob take us closer to May!