ubco-mds-2021-labs/dashboard1-group-f

A dashboard showcasing visualizations of surgical wait times in British Columbia

dashboard1-group-f's Issues

DocStrings

Tab 2 - split into 2 pages, move code to separate .py files

Editing tabs

Write README

Improve readme

Proposal

Your proposal should be no more than 1,000 words and include a sketch of your app. The proposal should be written as a markdown document (proposal.md) in your GitHub.com repo and include the following sections:

1. Motivation and purpose of your dashboard
2. Expanded EDA: "cleaned up" and expanded EDA and description of the data
3. Research question(s) you are exploring; you should aim to make these research questions compelling and substantial

You will be assessed on the reasoning underlying your proposal as well as the quality and clarity of your writing.

Each of the proposal sections are described below and include an example of what is expected. You don't have to write your own proposal exactly the same as the examples, they just serve as inspiration.
You will not be penalized if you can't implement everything in your proposal, or if your app changes due to technical or time limitations, but try to think about whether you think you will be able to implement it in the time frame of the course
(this is admittedly hard since you have not worked with the dashboard frameworks before, but it is good to have it in mind already in the planning phase).

Description of your app & sketch

Building from your research questions and usage scenarios, give a high-level description of the interface for the app you will build.
Remember to be realistic about your expectations and plans since you will actually be implementing this app (but again, you will not be penalized if you need to adjust a bit in later milestones).
It is better to design a slightly more limited app that you have time to implement well, instead of a complicated app that you don't have time to finish.
At the same time, you cannot just make a single barchart and call it a day.
The app needs to have a few plot panels, use the visualizations from previous students shown in lecture one as a guide as a complexity target for the final app.

You may choose to have two sketches, one for a realistic, achievable dashboard and another as a "stretch goal", something you can do if everything goes according to plan.

In this description you are not required to use terminology specific to Dash apps (i.e. widgets, components, etc...) or make reference to specific Python or R libraries.
Your sketch can be hand-drawn or mocked up using a graphics editor.
If you can show the app visual design & interaction design in a single image that is ideal, but if you need more space to show some other planned features of your app you can include max three images for this proposal.

The description should be about 200-300 words and live in the README.md file of your GitHub.com repository.
The sketch should be linked in the README.md file of your GitHub.com repository underneath the high level description so that the image shows up on GitHub.

Tab 2

Import csv into repo, setup file structure

Summary page with map, background information and orientation information

Because this dashboard is geared towards healthcare administrators, it does not need a map and basic background information. That being said, a map would be an interesting feature, both because it would look nice and because building it would be a good skill to practice. Additionally, some background information links and usage information would broaden the potential user base. This issue is for consideration in future developments.

Team work contract

A team work contract communicates specifically how the core group of people who are working together and gives more detail about the logisitics of working together and the expectations you have for each other.
This document will govern your working relationship and if done correctly, should help you manage and resolve any issues that arise.
MIT's online software construction course has a good description of what to put in a team work contract.
Some key aspects of the team work contract could be:

• How will work be distributed in a fair and equitable way?
• What are the expected work hours for the project?
• How often will group meetings occur (here is a nice article on meetings)?
• Will you have meeting agendas and minutes? If so, what will be the system for rotating through these responsibilities?
• What will be the style of working?
  • Will you start each day with stand-ups, or submit a summary of your contributions 4 hours before each meeting? or something else?
• What is the quality of work each team member expects from themselves and each other?
• When are team members not available (e.g., evenings and Sundays because of family obligations).
• And any other similar things that govern your working relationships.

Use this opportunity to use your prior knowledge/experience to improve your teamwork, communication, leadership, and organizational skills.
You will need all of these for your capstone projects (and beyond)!

Activity for building a team work contract

We recommend that generate the team work contract according to these guidelines

• For 5 minutes, each team member will silently write out 4 different suggestions for the team work contract on their computer.
• Next, paste all suggestions into a common Google doc (or similar)
  and arrange them to put similar suggestions together.
• Spend 10 -15 minutes discussing the suggestions
  and decide which ones you will use for your team contract either by consensus or voting
  (you can of course add new ones at this point if any were missed earlier)
• Add the final contract in a file called team-contract.md in the repo root
  (in organizations this file might be kept internal instead of committed to a public repo).
  • These are the principles you adhere to when working.
  • This file should only be updated if there is agreement between team members to do so.

Version Release & Submission

Tab 1 - split into 2 pages, move code to separate .py files

Link Slider and Quarter output to plot input

Heroku deployment

Contribution guidelines

• It is a good practice to include information about how others can contribute to your project somewhere in your repository which is typically done in a file called CONTRIBUTING.md in the project root.
• You can read more in the Mozilla Open Leaders training program, get inspiration from other open source projects such as pandas or the mozilla leadership training, or use this simple template:

  • We welcome all contributions to this project! If you notice a bug or have a feature request, please [open up an issue](<insert link to your GH issue tracker). All contributors must abide by our [code of conduct](<insert link to CoC file).

Heroku Deployment

Pick a suitable license

Pick a suitable licence. MIT and BSD-3 are common good options for open source projects. The carpentries has a short primer on licenses (optional read).

Build dashboard skeleton

Code of Conduct

In an attempt to create a safe, positive, productive, and happy community, many organizations and developers create a code of conduct for their projects, which is typically documented in a file called CODE_OF_CONDUCT.md in the project root.
A code of conduct in a Data Science project informs others of social norms, acceptable behaviour and general etiquette.
It is more outward facing than the team work contract discussed above.
We recommend Project Include and Mozilla Open Leaders for a comprehensive guides to writing an effective Code of Conduct (both optional reads).

We believe that an effective code of conduct should include:

• A statement on inclusivity and harassment free involvement in the project.
• Details on expected behaviour and unacceptable behaviour.
• A procedure for reporting unacceptable behaviour.

Sample Codes of Conduct:

• Contributor Covenant
• UBC Data Science 100 CoC
• Python Community CoC
• Tidyverse CoC
• Pandas CoC

Contribution Table

Reflection

Navbar - add new tabs, add sliders/radio buttons?

Tab 1

Reflection

Update Readme