Update high level documentation for new contributors

[beakerandjake]

As a new contributor, I think one of the challenges coming into any new project isn't necessarily writing code it's getting a high level context of the project and codebase, the "whys" and "wheres" vs the "hows".

An additional challenge is the current efforts to re-write the project with react. I think that without some high level documentation it can be confusing for new contributors to see this mix of new react and legacy components and leaves them unsure about where their code should go.

Here's few ideas ideas for documentation that could be added which might help contributors get up to speed quickly:

• A project overview section of the readme, providing context about the legacy code and the fact that there is an ongoing react migration. Nothing too detailed, some info about the original code base, how it was structured and the history of the current migration efforts.
• An overview of the migration, example: "The long term goal is to port the legacy embry components to react, bringing the experimental layout to feature parity with the legacy layout..."
• Some sort of roadmap of the migration, example: "Port all legacy components to react -> promote the experimental layout to become the default -> remove the legacy layout, etc"
• Additional emojis in the Directory Structure section of the readme to indicate which directories contain mainly legacy code (if applicable).
• Overview of the experimental vs stable layouts.
• Links to PRs which provide a good example for migrating a component to react (maybe even a new label so these PRs can be searched for)
• A step by step overview of how one can contribute to the migration. For example lets say a contributor wants to migrate component foo, what are the steps for doing this? Are there different ways of doing it, can they just make a react wrapper around existing code? Can they just re-write the whole thing? Is there a preferred way? Where should the new code live in either case?
• Guidance about where development efforts should be concentrated. If someone wants to do a bug fix or add a feature should only do their work in stable, experimental, or both?

Feel free to add ideas! I figure actual changes will be tackled in their own pull requests, but I wanted to create a meta issue to discuss what type of documentation the community thinks would be helpful to see created. I think creating such documentation is worthwhile and lowers the bar to contribution.

[IlmariKu]

I was asking about the same thing over on the Discussions side. Here's the thing I was wondering.

"I've been thinking of contributing to Jellyfin via code and I was looking around the code for starters. I noticed so, so many packages, many of them filling a same purpose. For example, the project is full of PostCSS, but there's also all Material-UI libraries available? Which one is it that the project is heading to or going to use?

The styling was one issue, but I also just felt the sheer weight of so many packages. Do we have a guideline or and ADR-decision on what we are going to use? Sorry if it's a dumb question, I'm new here after all

Or more, there's vite and tests running with vitest. Which is it? Is the project heading out from webpack? Is there any place where these decisions are documented? Or is the even a decision?"

[IlmariKu]

Directory-structure would be nice, but I would want to know the decisions around packages and tooling as well. There are so many different ways to implement currently.