[Proposal] Development workflow
See original GitHub issueBusy gets more and more external and internal contributions. We should make sure we are capable of scaling from tens to hundreds of contributions weekly. Because of that, I would like to propose some changes to our development workflow:
- Making sure our repository stays clean.
Our repository is already at 4600 commits and it makes it would be hard to revert to some point in time if needed. We can’t (shouldn’t) update old history, but we can make an effort to keep our future git history better. To do this we should enforce few rules:
- Don’t EVER push to
dev
ornew-design
without pull request. It doesn’t matter if it’s a just simple fix or anything else. No code should go to the repository without review (see below). - Don’t use
busyorg/busy
for your local work. Our repository should only have branches that are relevant to our release cycle. We might want to havedev
andnew-design
branches and additional branches for bigger pieces of work that could have multiple contributors working on them. It would be hard for external contributor to work on wallet page alone, but if we would create a branchwallet-page
and allow multiple contributors to create PRs to that branch with small chunks of code (like fetching data, styles, displaying data, adding tooltips, adding minor functionality) it would make it easier for them to contribute. After we agree thatwallet-page
is finished we can approve and merge PR fromwallet-page
tonew-design
. Any work that won’t require contributions from more than yourself (so usually some small changes) should take place on a fork. If there is branch inside busy repository you should never push to it directly, use pull requests instead. - Use merge --squash or rebase if merging more commits than desired. If it makes sense to squash commit into one, do it. If you feel that one commit is not enough, rebase your work into multiple commits that have clear description and purpose. If you have a clean commits with a proper description, you can merge it just fine (but I don’t think we should ever have bigger merges than 2-3 commits and it should be reserved only for big changes).
- Limit number of people that can merge pull requests. It’s better to wait some time to let other developers get familiar with changes and share their thoughts on those changes than merging improperly or with low quality, buggy or dangerous code.
- Be strict about what goes into our repository. Introducing bad code is easier than turning bad code into good code. If we let bad code in, this will require additional work to get it rewritten properly. Don’t do this: https://twitter.com/iamdevloper/status/397664295875805184. If you are not 100% sure about something ask others for help.
- Don’t EVER push to
- Improve the quality of issues and pull requests.
- Use good explanation for what is going on. Not all Trello cards have been migrated to GitHub issues yet, so don’t reference them in PRs or issues, because they are not public. Explain what are you doing so even people that don’t have access to Trello can understand what is the thing that is being worked on. This will prevent situations when two people are working on the same thing simultaneously.
- We should make sure that we don’t have multiple people working on exactly the same thing at the same time. We use issues so we can discuss who will work on some bug or feature. If someone wants to take on this issue, they should be assigned to that issue.
- Use descriptive names for commits as well as issues and pull requests. Pull request title should focus on changes, not say what kind of bug it does fix (so Don’t show already followed users in recommendations instead of followed user appears among recs after reloading the page - the former makes it clear what has been changed, the latter sounds like it’s adding new bug).
Issue Analytics
- State:
- Created 6 years ago
- Reactions:2
- Comments:6 (6 by maintainers)
Top Results From Across the Web
Proposal Development Workflow | Research Administration
Overview of steps required in proposal development process · Read the funding opportunity guidelines · Get organized · Understand your team's roles and ......
Read more >Proposal Development Process - AcqNotes
A Proposal Development Process helps organizations respond to a buyer's Request for Proposals (RFP). An established proposal development process should help ...
Read more >Proposal Development Process
Summary of the proposal with brief review of the major points in the statement of need, objectives, procedures, evaluation, and dissemination components; should ......
Read more >Proposal Development Process/Flowchart
Proposal Development Process /Flowchart. Develop. Project. Concept. Locate. Funding. Opportunity. Determine. Eligibility. Proposal. Planning. Proposal.
Read more >How to Create an Organized Proposal Process From Start to ...
Key Solutions Blog · Establish a Proposal Schedule. Once the team is assembled, the Proposal Manager should immediately start working on a ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I think we should have the branch
Got this schema from these branching guides that we can follow:
https://gist.github.com/digitaljhelms/4287848
https://datasift.github.io/gitflow/IntroducingGitFlow.html
master
andstable
it’s less confusing.stable
would be versioned and used for production. Whilemaster
is used for development. We can setup the domain staging.busy.org with master branch to test every new version before it get released. It would look like this:dev
andnew-design
that are used for production deploymentvoting-slider
orwallet-page
that are used for tracking work for certain feature/fix. Other branches should be hosted on forks (https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow)Workflow
This is just proposal and should be discussed to make sure we can get the most out of it. We might want to start using some of those ideas already to make migration to this new workflow as smooth as possible.
Branches
I think we should have two kinds of branches:
dev
(Busy 1) andnew-design
(Busy 2)Core members shouldn’t use busyorg/busy for local work and use forks instead (https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow).
Issues
Should be used for discussing new features, ideas and bug reports, before starting work on anything. We should have a plan before writing code. Before anyone starts working on it, we should know how it’s supposed to work, look like and how we want to achieve this. If someone wants to work on this issue they should be assigned to that issue, so we would avoid having multiple people working on exactly same thing. It’s okay to have multiple people working together on same concept, but they should agree what their responsibilities are we should provide
progress
branch for them so they can cooperate. It’s highly recommended to give abstract opinions at stage of planning in issue. When work has started and PR has been created there should be only code-related discussion, ideally without any “we don’t need this” comments.Pull requests
After planning phase person that has been assigned to relevant issue should create PR shortly after writing first code. This allows us to track progress, notice problems early and solve them faster. In case of small changes PRs might be created after work is done. Pull request should clearly reference issue that it concerns. (using
fixes
andcloses
keywords). It should include list of changes made (in terms of UX/bugs not code changes, unless it’s code related pull request). Pull requests are good place to have code related discussion. If there is anything that needs be discussed that is not related to code and implementation use proper issue for this. After work is done notify others and request review. Before merging:Reviews and approvals
Take your time to review PR properly. If you don’t have time to review, ask somebody else to do this for you. Request changes when you think that this code shouldn’t land on target branch. Use comment when you don’t have strong opinion on some piece of code. Approve if you think that this code is worth merging into target branch. Make sure everything works properly - you can review new functionality using heroku deployments, ideally you should test it locally to see if it doesn’t cause any problems on your machine.
General information
Issues and pull requests titles should be clear and easy to understood even without reading description. If there are issues or pull requests with low quality titles update them. For branch names use
kebab-case
.