From Joomla! Documentation
Joomla Hata Biriminin (JBS) amacı Joomla! hataların sayısını azaltmaktır.
Bu yalnızca CMS için değil, her Joomla (alt) projesi için de geçerlidir.
Joomla! Hata Birimi şu yaklaşımları izleyerek Joomla! hataların sayısını azalttı:
It is not up to the JBS to provide support on those channels (although it would be appreciated), but to
- olası böcekleri saptayıp doğrulamak,
- postere, izleyicide bir konu bileti hazırlamasına yardımcı olun
- create an issue ticket on the tracker, if the poster is not able to do that
- leave a reference to the tracker item on the channel
The sooner this happens after the original post, the better the overall perception will be.
The main tool - and thus the single point of truth - is the issue tracker, which again is a customised view on several GitHub repositories. All relevant information from the channels mentioned above are consolidated here.
2. Confirm bugs using a test.
Ideally, a bug is confirmed when - and only when - a test exists that reproduces the issue. That test will prove the validity of any fix.
This is not possible in full extent currently. The JBS will work closely with the Automated Testing Team to provide a library of test functions that will allow non-coders to provide a test description that can be turned into test code (calls) automatically.
Until that library exists, manual confirmation is conducted.
In conjunction with the confirmation, JBS also makes sure each issue has the correct Type, Severity, and Priority.
3. Fix bugs
The first approach should always be to get the original development team of the buggy feature to fix the issue - they know so much more about the feature's domain than a JBS member can. JBS will help them if needed with implementing tests.
If the development team can't take over, a fix will be provided by JBS contributors.
4. Follow up issues
Whenever an issue gets stuck, JBS leadership will investigate the reasons and put the issue on track again.
5. Testing patches
Currently, two positive explorative tests are needed to accept a patch. JBS will support the Automated Testing Team in creating a Docker based test environment that allows to run the test suites on different web servers, with different databases, different PHP versions, and so on. The Product Department defines the stack matrix.
6. Prevent bugs during development
The JBS members help the development teams to create a test-first culture. Finding bugs during development is the most effective way to zero bugs.
7. Support Pizza, Bugs and Fun (PBF) events
There is a culture of organising Pizza, Bugs and Fun events from time to time - by Joomla User Groups or in conjunction with a JoomlaDay or other conferences. Given enough handling time, JBS members will be available on Glip for assistance.
Team Lead, Assistant Team Lead
These two members lead the team as defined in the bylaws. Their main obligation is to co-ordinate the team's activities and collaboration with other teams.
All members are supposed to subscribe to Forum, Mailing Lists, Social Media channels, and StackExchange mentioned previously.
Members help users with handling issues on the tracker, with coding fixes, with sending pull requests, as well as with reviewing and testing patches.
Üyeler, tüzüğe göre oy hakkına sahiptir.
Any person reporting bugs on the tracker, providing fixes, sending patch pull requests, or reviewing or testing patches is considered a JBS contributor.
Katkıda bulunanların tüzük uyarınca oy hakkı yoktur.
- Joomla! Forum, especially Joomla! CMS 3.x Bug Reporting Forum
- Google Groups Joomla! CMS Development and Joomla! Framework Development
- Linkedin Official Joomla! Users Group, Facebook Joomla! Group
- StackExchange Joomla Q&A
- A workflow has to be defined for that, because the test must be executable with and without a proposed fix.
- This will be Gherkin based acceptance tests. The syntax is very easy to learn and is targeted at non-coders.
- No code should ever be merged without tests! We've seen Joomla breaking because of missing tests way too often.