Add FAQ page

[darkturo]

• Extends the schema with a field to hold the content for a FAQ in markdown.
• Add resolvers to retrieve the content of this new field
• Adds submenu on the main round pageon the main round page

[darkturo]

I have an issue with the update resolver, I don't seem to manage to store the changes on a FAQ page :-/

Perhaps you can see the problem and hint me in the right direction? @aerugo

[Powersource]

It's because you send the faq to editRound but you haven't updated that mutation in ui/server/graphql/resolvers/index.ts to actually store it in the db. You'd also need to update the prisma schema to be able to store it.

Are you sure this page is needed? The About page is supposed to fill this purpose.

[Powersource]

Also are you sure you want to fork the project like this? Personally I'd be terrified of it since I'd potentially take on a lot of maintenance work. If our team agrees with a change we'd be happy to merge it upstream.

[aerugo]

@Powersource - the deal with the Borderland will be that they are 100% responsible for their own instance if they choose to diverge from the main Cobudget fork. I would like to give that flexibility. We just host whatever is in this repo.

Do you see any potential risks with that I am not seeing?

[Powersource]

No for me it's fine, I'm just warning out of sympathy 😁

[aerugo]

Right, but are you (@Powersource) seeing risks that you would be terrified of that you think might be missing?
You are often more conservative with risks than I am so I am genuinely asking your advice.

What I would like to achieve is to give the Borderland team flexibility to implement half-crappy solutions that solve problems for them in a quick and easy way, without those solutions needing to be good enough for cobudget.com. Some of those changes might indeed be good enough for cobudget.com and we could then cherry-pick those into a fork of our own and polish them for production.

I would advise against making changes to the server or data model though, since that might make it harder to keep in sync if they choose to revert back to the main fork. But I think that will not be necessary - I think the Borderland would mostly need to make changes to the client. Exceptions might be some new auth strategies for Passport to use oAuth with the Borderland Keycloak, and some plugin scripts to integrate with other systems. But since auth strategies and scripts are isolated files, it should be relatively simple to keep track of those changes.

[Powersource]

As long as the modifications stay small like this it might be fine. But even then, as you mention, db changes might make things unproportionally hard. Let's say in a year or two, upstream has a major db migration but doesn't migrate the faq field because it doesn't exist there. Then when that's merged into this repo, suddenly all the faq data is gone from prod and you need to restore from backup.

There's also the consideration that, since it's on a volunteer basis, what if darkturo doesn't feel like maintaining this in a year or two, are there other devs in the borderland comfortable with this stack?

For the borderland these things might also be made easier since it's a yearly event, maybe you're fine with throwing out the whole db every winter, allowing you to maybe mostly ignore db mismatches.

[aerugo]

Yeah, so the solution is then probably to be clear about that Cobudget does not take responsibility to fix things on the divergent fork, and that the person holding the responsibility to merge to production should be very conservative about anything that touches the database.

Which, in turn, brings us to that this PR might be an example of something that costs more than it is worth as it requires DB changes. What do you think @darkturo?

[darkturo]

Thank you for your feedback @aerugo and @Powersource !

I have no plans or aspirations for my participation in this project other than facilitating small features for the Borderland 2022. Obviously, as an engineer, my aim and motivation are to create good and reusable software, but I can live if the modifications I do in this fork are lost in time together with the context of the Burn.
Nevertheless, I must say that transcending the fork and ending up contributing to cobudget is something that interests me since I am part of diverse communities where cobudget could be of help.

I read your advice about not making DB changes. So far it's been a good exercise for me to get to understand and know the project, a deep dive into typescript, react, and graphQL (I heard about it for the first time in 2018, but didn't grow in me).
In general, I don't have a solid reason to push for this or other features that need DB changes... other than, experimenting, learning, and helping the Borderland dreams team.

For now, I'll try to make this PR fully functional (following @Powersource's suggestions) when I have a little more time. Also, speaking with @aerugo, this evening, I've got the idea of defining the graphQL schema differently, in a way so that it does not collide with the current definitions: i.e. instead of extending round, I could just create a new object/table (perhaps in a new namespace) with the attributes I need, then most of the syncs with the parent fork should come easy... until the moment cobudget decides for a big DB migration or similar.
But, I'll also the Dreams team about their thoughts on using the "About" page to add FAQ.

Finally, I don't know if I'll be maintaining this in the long term, but I'm open. I guess only time will tell, maybe I find collaborators in the Borderland that are up for the task, or maybe I end up liking this tech stack and I become the maintainer for this fork.

Thanks again 🎸