Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
Overall, we use a fork-and-branch model. The rest depends on where in the project lifecycle things are and what our customer-dictates are.
Early in a project-lifecycle, there often aren't "issues", per se. It's usually "we need IOC by <insert date that's some fraction of the length of time that it likely ought to be>". It usually works out to a flow like:
initialize project in relevant git-service: do the initial commit so you can begin to branch; set up branch-protection on the base-branch(es)
Gen-off a "project-scaffolding" branch: add issue templates, MR/PR templates, contribution guides, CoCs, baseline test-configs (syntax linters for the languages/frameworks to be used), etc. Then merge that in
Start forking off IOC-supporting branches (naming is ad hoc)
Because we do work for multiple customers, things begin to deviate once the above is done. Some customers want issues managed in Jira. Some want issues managed elsewhere. Some are fine leaving them wholly contained within a given git service. Once we're to the point that there's discreet defined tasks that need to be individually coordinated and tracked, then we start using the customer-preferred tracking system. For tasks tracked wholly within the git service, we usually just do "Issue_<NUMBER>" to reflect the git issue-ID. If customer is mandating Jira, then we usually do "<PROJECT_ABBREVIATION>-<NUMBER>". For other issue tracking systems, we do either whatever's native to that system or whatever the customer asks.
...And if we're doing stuff on spec (anticipating a need for a customer or our own organization), then it's pretty much dealer'sdeveloper's-choice.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Overall, we use a fork-and-branch model. The rest depends on where in the project lifecycle things are and what our customer-dictates are.
Early in a project-lifecycle, there often aren't "issues", per se. It's usually "we need IOC by
<insert date that's some fraction of the length of time that it likely ought to be>". It usually works out to a flow like:Because we do work for multiple customers, things begin to deviate once the above is done. Some customers want issues managed in Jira. Some want issues managed elsewhere. Some are fine leaving them wholly contained within a given git service. Once we're to the point that there's discreet defined tasks that need to be individually coordinated and tracked, then we start using the customer-preferred tracking system. For tasks tracked wholly within the git service, we usually just do "
Issue_<NUMBER>" to reflect the git issue-ID. If customer is mandating Jira, then we usually do "<PROJECT_ABBREVIATION>-<NUMBER>". For other issue tracking systems, we do either whatever's native to that system or whatever the customer asks....And if we're doing stuff on spec (anticipating a need for a customer or our own organization), then it's pretty much
dealer'sdeveloper's-choice.