List view
The Discovery Phase aims to properly research and document the status quo. It will be a thorough analysis of source code, trac tickets and contributor discussions to decipher the reasoning behind the current implementation and what the requirements, strengths and weaknesses are. Documentation will be written in parallel, logging all findings and producing a better onboarding process for this component. Characterization tests will be written to be able to detect regressions when making changes in phase 3 later on.
No due date•0/11 issues closedThe Design phase will examine all the findings from phase one to design a new version of the bootstrap component that meets all the requirements and strengths while reducing some or all of the weaknesses and improving reliability, flexibility and performance. We want to avoid having yet another component update that just grows organically. There should be strong principles in place that make sure that the new version is not only backward compatible but also forward compatible.
No due dateThe Execution phase will create a modified fork/branch of WordPress Core, to allow for collaborative work on this new iteration of the bootstrap component. Through automated tests, refactoring will be guided to implement the design from phase 2. The characterization tests from phase 1 will make sure that compatibility remains a given, even for “compatibility-enforced bugs”. Optional mechanisms to get saner results in such cases will be discussed on a case-by-case basis.
No due dateThe Merge Proposal phase will be the final phase of the project, identifying a clean merge process and a proper migration path to merge the new version of the component into Core. Metrics will need to be defined to have measurable and achievable goals that can objectively tell whether the Component is ready to be merged.
No due date