Skip to content
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
144 changes: 144 additions & 0 deletions WRITEUP.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,144 @@
# Please contribute! Reword, delete, add, anything

## Team Communication
Weekly development check-ins are held on Tuesdays at 8 pm EST. The team uses Google Meet, which is more cost-effective (free). The team also uses Slack for daily communication. For all documents the team relies on the [qg-docs GitHub repository](https://github.com/QueerGlobal/qg-docs) unless individual Google Docs files are utilized. All sources are pinned to the relative Slack channel.

### Communication Between Engineers - The Communication "Culture"
Once topic-specific channels were created the conversations became free-flowing.

The #development channel is the hub where all ideas reach everyone the fastest.

For all frontend-oriented work there are the QG GitHub account's [issues](https://github.com/QueerGlobal/qg-frontend-v2/issues) and [pull requests](https://github.com/QueerGlobal/qg-frontend-v2/pulls) opportunities to discuss code-specific details.

Note: Initially there were no standards in place for things like how to write pull request comments, code formatting and style, and how to distribute work to new team members, regardless of their experience level. We all had to work together through situations usually laid out ahead of time by management for an established entity. We became our own AND each other’s “Manager”. The end result is our current culture: Where own standards for how to work together are accepted while at the same time being courageously open to and ready for inevitable needed changes. There is an acceptance of our autonomy through trust.

### Communication with Interested/New Volunteers
Deacon is the QG Co-Founder and is ever-present to greet one and all. In all Slack channels, Deacon is the one who will direct volunteers to the QG family.

Once team members join the QG Slack, and Deacon announces them, they have access to the full family and is welcome to take initiative in introducing themselves in 1:1 conversations and in the general Slack channels.

Our project relies on individuals who tend to be self-starters; those who are comfortable with taking initiative on the Roadmap tickets as well as seeing the valuable app areas in need of building out first compared to other areas. This is a good thing because it means that the team is not bogged down with the need to micromanage.

## Product-Oriented Process
### The “Defined Problem”
Need for a new, modern, web application with immediate resources for networking with professionals, knowing the latest events, and building community for LGBTQIAA+ people, by LGBTQIAA+ people.

### The “Solution”
Create a web application that serves as this source/product. A web application, vs a website, because it will be interactive and have a database that stores relevant resource data.

### Methodology
Agile? Scrum? Waterfall? TBD

A series of Roadmap boards are used for task distribution, broken up into “tickets”:
[Frontend Roadmap](https://github.com/orgs/QueerGlobal/projects/1)
[Infrastructure Roadmap](https://github.com/orgs/QueerGlobal/projects/3)
[QueerGlobal Development Onboarding Documentation](https://github.com/orgs/QueerGlobal/projects/2/views/1)

### Targeting User Needs
From surveys and informational interviews?

From UX interviews?

Research?

### Design
A traditional web application structure of main pages as well as unique features such as sharing artworks.

### Model
Wireframes, mockups, prototypes, etc. TBD

### Application Architecture Overview
List of minimum requirements for local development
- Golang TBD
- Node JS LTS (as of June 2023) version
- NPM version TBD
- MySQL version TBD
- ESLint Extension
- Golang CI/CS Lint
- Precommit, a language-specific commit checker
- Etc. TBD
Comment thread
Mekebrown marked this conversation as resolved.

Create-React-App, Node JS?, MySQL?.
Handling stale API data?
Pull request reviews consist of engineers across the team zeroing in on all aspects of each other's code.

[Golang](https://go.dev/)
[MySQL](https://dev.mysql.com/)
[React](https://reactjs.org/)
[Create-React-App boilerplate](https://create-react-app.dev/)
Dedicated GH repo for client front-end app
Dedicated GH repos for microservices

Logging - Management Tool
Client (FE): TBD
Database: TBD
Server (BE): TBD
API rates, stagnant data, observation?
Network: TBD

Version Control - Git; Repositories housed on GitHub

As of June of 2023, every engineer can access, review, approve, and/or block a pull request

Pull request template and labels created by team and are currently being formalized [in this document](https://docs.google.com/document/d/1prQ08FbkMTHAMC2-BvpEeLSk3_YoRl18owza9_t3xJY/edit?pli=1)

### Testing
A demo-repository is being planned for a staging version of the app. Here is [a spreadsheet of details](https://docs.google.com/spreadsheets/d/1xlDfIMQn_NXb4PbE8QkncdGxw6H-h9RGGHn8_45z5r4/edit#gid=584784234) for future group testing

Unit, automated, QA, user, performance - TBD

To be used: [Accessibility Conformance Report, 2018](https://www.fdic.gov/about/doing-business/acquisition/acr.pdf) - Information Technology Industry Council

Testing risks? Taking more than expected time? What do do with faulty tests; TBD

If signup, login, and/or payments tests are not working, this is a level 1 severity. Take the site down immediately.

### Documentation
A GitHub repository of documents, future Wiki, TBD.

Will cover requirements for product functionality, what went into the designs, architecture decision making, testing, group process, etc.

Changelog? TBD

Database relations broken down in [this document](https://docs.google.com/document/d/1rt0V8w4bygqfRPnhwbbE9FCcKIAJI2yT1as8AMG_ehA/edit#heading=h.yfunt0g4gpy6)

### Deployment
AWS?

Other cloud environment?

A/B testing? SEO? TBD

If signup, login, and/or payments are not working, then the app is not working. Take the site down immediately.

### Measurements/analysis
Quality metrics, API connection rates, user feedback, TBD. Analytics is critical for the effectiveness of the product.

Example of measurement performance, from the open-source tool [Lighthouse Chrome DevTools report on performance metrics](https://developers.google.com/web/tools/lighthouse#devtools)
- Install Chrome
- Open Chrome DevTools
- Select the Lighthouse panel
- Hit "Generate report"

Lighthouse Node module - For local report generation

For testing web pages in production

If signup, login, and/or payments are not working, then the app is not working. Take the site down immediately.

### Maintenance
Bug-tracking procedures; TBD

If signup, login, and/or payments are not working, then the app is not working. Take the site down immediately.

### Educating the user
FAQs, video tuts, video interviews, TBD

## Mobile Development
Probably not but TBD

## Marketing and Promotion
TBD

References:
[IEEE 829 Test Plan Example, Ecommerce Website Cross Browser Testing Test Plan](https://docs.google.com/document/d/1F1TUX5BkviRbw8auI2Xq2K2wyGTS-Ag14DRymiELmzc/edit)