- Initial task is to get Gladdy’s process in the wiki for the rest of the dev team to read and get an understanding of
- Integrate into dev flow
- Add a description of your new features as they happen and make the content a part of the review to make sure it is clear and concise
- Areas would include:
- Q&A/FAQ
- Onboarding
- Developer section
- Setup
- Local dev guide
- Various documentation of measure ecosystem
- Measure, Redpen, ExamResponses, etc
- DB’s
- Cassandra, Postgres, Mongo
- Setup. Debugging, modifying
- Chart of all the different DBs tables and their respective relationships
- Cassandra, Postgres, Mongo
- Staging system(s), setup, debugging, modifying
- Production system(s), setup, debugging, modifying
- Docker setup, debugging, modifying
- More organized documentation and process to getting a new dev oriented with the system asap
- Assign a dev to be their “Measure Mentor”, so they can help and assist in any questions the new dev has
- Comprehensive documentation (likely would exist in the wiki) on how to set up their local environment, debug issues and manager their system
- Listing of necessary and helpful software
- A listing and quick rundown of all the respective sites we use and how we use them (jira, new relic, github, etc)
- A “who’s who” of each department and what they do
- Developers could reference this as a guide with examples as to how things should be structured, from their development environment to the code itself
- Monthly tasks given to the group to enhance their knowledge in a respective area that would be helpful, to measures and their growth
- Non-obligational, but to incentivize, potentially contribute to respective houses points If complete
- At least two reviews to pass, unless extenuating circumstances arise
- For bigger tickets, encourage a more descriptive rundown of the PR, what it entails and how to test it, get it working, etc
- For particularly large tickets/features, have a scheduled weekly quick state check-in with either lead or senior dev to make sure everything is going well
- Able to identify issues before they become problems
- Will help with timeline management, as the individual checking in can help determine remaining timeline
- Bi-weekly (perhaps monthly?) gatherings of measure team in a more relaxed setting to discuss code related things, what they’ve learned, what they’re interested in, or just to simply joke around and get to know each other, maybe only half-hour
- Could really help team cohesiveness and help get an understanding of each person
- Keep the team energized and passionate to work together and try new things
Awesome, looks like we're thinking along the same lines but you have some extra ideas I hadn't even considered yet! Thanks Josh