-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Write a project design doc #202
Comments
I really like the direction this is going. Only thing that comes to mind right now is how to divide information between this page and our README and other documentation that (likely) will be proposed down the line. From a quick scan I see CL also has a Contributing Guidelines doc. We talk about some of this content, in addition to how to setup a dev environment in our README. |
Some insight into our doc decisions:
|
…r corrections (#198) I want to preface this by saying that I'm planning on rescoping #187 and adding a follow-up issue. In this PR, I address parts of the original spirit of #187: * documenting the prod CD pipeline * updating relevant portions of the docs to be *more correct* * adding a licensing/attribution section * adds TOC I want to move the discussion around Next.js, as well as the general design choices, to a project design document not unlike the one for [Creative Lab's website](https://github.com/UCLA-Creative-Labs/sunshine/blob/master/DESIGN_GUIDELINES.md). More in #202. closes #187.
Wanted to bump this issue (@annaguo1012 and @advaithg) and also wanted to mention that Regina has been working on some great documentation for Teach LA's high-level goals + implementation strategy, and might be a good person to consult if she's free / can share the doc with you. |
👀 👀 owo I'd be down to chat/share the doc if it's helpful! TeachLA was also thinking of having a project plan doc and such if that's something y'alls would ever want to discuss |
i'd love to help work on this; were y'all also considering making a design doc a requirement for every issue/PR perhaps? |
slide on in :)
Hm, that's up to y'all - it probably depends on the scope of the issue, but at the end of the day this is all in your hands now - excited to see what happens! |
Thanks for bumping this, Matt! I think it'd definitely be helpful to have this done before we start onboarding our new interns in the winter. @reginawang3495 @dtjanaka thank you both for offering to help too hehe. Maybe we could set up a meeting sometime soon? (bearing our midterms schedule :,)) |
It’s more like I’m open to helping if needed :) I don’t necessarily need to be in the calls!! |
More on this: starting last spring the dev team decided to have project outline documents that serve as living documentation so that when legacy projects get passed down from teams to teams, we can make the developer transition easier than ever. (linked template doc here!) (shout-out tla for starting the template i based this template off of) It covers a lot of stuff for developers like above, but also has a couple things that are great for the overall vision of a project like what exactly does the project do, who's the Points of Contact for project purpose vs. design vs. tech, etc. and a link to it will be put inside of the CONTRIBUTING.md at the root of each project. We're currently making one for the legacy projects and will def make one for the website as it's the project that gets passed down the most! |
One of the things I think Creative Labs does particularly well is writing a
DESIGN_GUIDELINES
document. They outline their tech stack, file/component structure, approaches to styling and modularizing and in general, how they make decisions. I think this piece of documentation - if it's updated - is invaluable for onboarding new members and making our project more contributor-friendly.I propose we make a project design doc. We should discuss (with heavy inspiration from Creative Labs):
A tricky portion is that we are writing this after-the-fact, rather than driving a project with a set of design guidelines already in mind. However, this document can also be a goalpost for the direction of our project - in transitioning to React hooks, for example.
This will also be a team-driven effort, and I'd love to see someone else on the @uclaacm/dev-team champion this!
Related to #187; inspired by #198.
The text was updated successfully, but these errors were encountered: