-
Review default and custom issue label schemes.
-
Design custom github project issue labels.
-
Design custom github project board columns.
-
Git + Github Workflow Diagramming Needs Support
- From issues to pull requests, test-driven support on github is conspicuously absent.
-
The beginner meta-pattern is { Red => FAIL, Orange => PASS, Green=> SUCCEED }
-
The expert meta-pattern is { Red => FAIL, Orange => SUCCEED, Green => REFACTOR }
-
We learn best by doing, and by teaching others to do for themselves.
-
All github project work starts with issues.
-
All testing compares expectations vs actual results. Match = success. No match = fail.
-
In all cases, testing sufficiency is the goal towards:
- recovery
- prevention => see mission critical prevention below
- automation
- Six testing targets:
- new feature testing => UTF-8 character set support
- new bug testing
- regression testing
- new release testing => requires open source license
- ongoing doc testing => requires license => how do we test docs?
- i18n testing
-
unit
-
feature
-
security
-
performance
-
integration
-
end to end system testing
-
Four Quadrants Of Risk:
- severe + likely*
- severe + not likely*
- likely, yet not severe
- not severe + not likely
-
- The first two are paramount for prevention.
-
Github Issues are how we report software problems that are reproducible. This way other with the same problem can confirm or deny their experiences trying to reproduce software problems. If those problems are either not reproducible or not documented, for whatever reason, then support escalation is required. From issue writeup to composing excellent git commit log messages, seeing good examples is an excellent start.
-
https://github.com/codeforamerica/howto/blob/master/Good-GitHub-Issues.md
-
Test cases set it up so that we can rerun same tests with different inputs and outputs. So, a test case has many test runs. Test Cases --< Test Runs
-
-
How do we know when git or github itself has changed?
-
What about corresponding doc changes?
How do we label issues to indicate that we:
- need support (of what kinds)?
- need more evidence (what kinds)?
- are not reproducible?
- are reproducible, yet inconsistently so?
- are about docs, rather than tools?
- are about i18n, rather than tools?
- should first test on linux for authoritative options? => Windows issues and OSX issues are support issues
- need a diagram?
- need roadmap and/or work milestones?
- need roadmap and/or team workflow milestones?
- spans multiple projects?
- has been reviewed and is ready for project board?
- Needs explicit test?
- Needs an owner
- Neds a tech review / support.
We will have label sets to help us tag our issue remediation workflows.
-
Github Issue Labels Defaults:
- bug
- duplicate
- enhancement
- help wanted
- invalid
- question
- wontfix
-
Github Project Board Column Defaults:
- none
- to do
- in progress
- done
-
??: What are issue data points?
-
We will instead have label sets, starting with 'github-labels-defaults':
- LABEL: ITEMS
- issue stages: submitted, reviewed, accepted, assigned, backlogged, rejected
-
Where we can have issues automatically labeled by github actions, we will do so.
-
The following tools have changed very little in 20+ years:
- bash: default shell in linux
- git: distributed versioning tool created by Linus Torwalds, the inventor of linux
- sql: database standards ( DCL + DDL + DML = SQL )
-
The best learning opportunities for test driven approaches depend upon carefully selected sample apps and scripts.
- What other bash testing tools?
- What other languages and testing tools?
- Elixir BDD Tools
- What is BDD and how does it relate to TDD?
- Test Driven Elixir Phoenix Dev
- TDD Elixir Phoenix Notes
- https://blog.appsignal.com/2021/11/30/three-ways-to-debug-code-in-elixir.html
- https://github.com/smeade/programming-elixir-book-notes
- https://docs.github.com/en/issues/tracking-your-work-with-issues/about-task-lists