This is the repository dedicated to the creation, ongoing development and management of the Mattapan Mapping application. This project is a collaborative project between http://powerfulpathways.org and http://www.codeforboston.org
The Mattapan Mapping project is a web application that is designed to be accessible while providing a similar experience/look-and-feel regardless of device. The project enables members of the greater mattapan community to share information in the form of photos, videos, audio overlayed with statistical and geographic information to provide a narrative of change in the community. This information can serve as a catalyst for change by generating conversations around the challenges facing the community in light of gentrification and housing affordability crisis.
This project will be run utilizing the Agile Kanban methodology.
All development tasks associated with the project will first be created as Kanban cards added to the following Kanban board:
https://github.com/codeforboston/mattapan-mapping/issues
Anyone should enter a card if they feel work needs to be done and they've searched and do not see it. We'll evaluate the new cards regularly. Similarly, all cards have the ability to take comments. Any concerns/advice/tips to improve the proposed change should be added as a comment.
In general, cards should have a descriptive title. Cards should be labeled with the feature(s) they relate to. And cards should have a clear description and acceptance criteria. Ideally, a contributor could start the card and not need any additional detail to complete the work.
Comments should be added as you make changes. If you are making lots of code changes, please make incremental commits and push your work-in-progress up to the main repo for review/discussion (more details below). The team/facilitator/feature lead may need to reassign work. Having any incremental work available makes this a more seamless process.
The project will have the following roles which, as an agile team, we expect to rotate so everyone gets some varied experience:
- Product Owner - a representative from the business side whose job it is to represent the customer and their feedback and prioritize the work.
- Architect - Facilitate decisions about any technology choices. Ensure that we address issues with security/maintaining code/handling the CICD process design
- Facilitator - Ensures that Issues and PRs are updated in an orderly fashion if the team is not doing it automatically. Ensures agile practices are followed and that documentation is updated.
- Feature Lead - Individuals lead specific features. They are responsible for breaking the work into issues and ensuring that the work is co-ordinated and delivered on time.
- DevOps Lead - This person leads resources assigned to coordinate code reviews, integrate changes, and release the software to production. DevOps may serve as backup to faciliator.
- PR - This person tracks the progress of the project and reports status each week to CFB and entices new people to join and helps them onboard. This person is also responsible for any other external communication the project has (scheduling interviews/working with outside organizations etc.
Everyone on the team has a voice and is encouraged to be involved/ask questions and participate. These roles help us understand who is responsible for what.
Current members include:
- Allentza Michel (powerfulpathwaysinc@gmail.com)
- Barry Fradkin (bfradkin@comcast.net)
- Brad Smith (brad@smithwebtek.com)
- David Morrison (morrisond7@gmail.com)
- James Gui (zkgui98@gmail.com)
- Jed Pittman (edpittman@gmail.com)
- Jeff Korenstein (j.korenstein@gmail.com)
- Kayla Patel (kayla.patel@tufts.edu)
- Sasha Hulk (srhu222@gmail.com)
- Shay McDonough (shay.m.mcdonough@gmail.com)
- Stephan Halarewicz (shalarewicz@gmail.com)
- Stephen McCall (stephen.mccall@gmail.com)
- Tejasvi Srigiriraju (sritejasvi@gmail.com)
Sharing of any of the information pertaining to these resources outside of the accepted team members is prohibited.
If you are unfamiliar, Agile projects generally follow the https://agilemanifesto.org/. This project's agile practices are described below.
This project uses the Task Branching methodology.
Any changes to the codebase should occur in a separate branch created specifically to implement the work associated with a specific Kanban issue card.
The naming convention for each branch should be: Kanban Task Name - Release Name.
For instance:
feature/implement-mapping-feature-1.0.0
Developers will create all changes necessary to implement a task/feature in a single branch, and each task/feature branch will undergo a team code review prior to being merged to the Main branch of the project. If you are having trouble/need assistance, you can push your branch early and start a pull request and prefix with WIP (work in progress). This will indicate to others it is not ready. However, this can help others stay up to date on code and get comments/feedback out early before code is fully baked.
Code reviews and merges will be submitted via Pull Requests. Please see the following links to familiarize yourself with the Pull Requst process:
For the time being only dedicated members of the development team will have access to this repo and any other external technical resources.
Commit messages should begin with the issue id they are referring to. So your commit message might be "#43-finished coding ui change."
Similarly, pull requests should have a similar message including the id e.g.: "Closes #43. 1. Finished all UI changes. 2. Cleanup some old comments."
Then when that Pull Request is reviewed and merged the issue will automatically be closed on the board.
While it is generally expected that any Pull Request will be related to a task, it could be the case you notice something that needs fixing outside of scheduled work, e.g. a broken test. In this case, create a branch chore/fixing_broken_test. Make your change and commit and submit a PR. This time, just provide a simple description.
All PRs should follow the standard testing process and include proof that testing has been run locally. We will also run automation in the pipeline, but tests should always be run locally and a screenshot/note included.
The Mattapan Mapping project makes use of the following tools to aid contributors....
Use of an IDE is strongly recommended.
Steps to build and run the application locally:
This project will have both automated tests that are part of the standard release pipeline and tests that can be run adhoc locally during the local development of changes. This ensures that code that is submitted for review has been tested.
This codebase makes use of the *** testing framework.
The test suites can be run using the following command...
This project makes use of the SemVer naming convention for releases:
MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.
All great open source projects start with amazing documentation! :)
Documentation describing the Mattapan Mapping application will be avaialble in this repo and at the following locations...
Once you have this repository cloned, you'll need python 3 installed.
Ensure it is running on the command prompt by running python --version
Next, run the application locally by running python -m http.server
Open a web browser at http://localhost:8000 if you're using the defaults above, to see the project.