Difference between revisions of "Outreachy 2022 Ideas"
Jump to navigation
Jump to search
(first draft) |
(added different sections) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | This page is part of [[Outreachy2022]] it exposes ideas | + | This page is part of [[Outreachy2022|Outreachy 2022]] it exposes ideas of what tasks could be done as part of the '''Improve the code quality of the Perl code of the Open Food Facts backend and website''' project'''.''' |
| + | |||
| + | Many of the ideas listed below come from the project timelines submitted by Yukti and Raquel. | ||
| + | |||
| + | ===Documentation=== | ||
| + | |||
| + | *Extend the existing documentation in POD format | ||
| + | *Document the API in the code (to be coordinated with the [[GSOD2022 API documentation]] project) | ||
| + | |||
| + | === Make the project accessible to more developers=== | ||
| + | *improve onboarding documentation | ||
| + | *IDE integration and debugging | ||
| + | *live reload | ||
| + | ===Code quality=== | ||
| + | |||
| + | * Investigate and remove Perl warnings during startup and execution | ||
| + | |||
| + | ===Tests=== | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
* Add integrations tests covering the API: | * Add integrations tests covering the API: | ||
** API is a good entry for integrations tests, it's generally clear what to expect | ** API is a good entry for integrations tests, it's generally clear what to expect | ||
| − | ** As project [[GSOD2022 API documentation]] will document, it would be cool to insure we never break the API | + | **As project [[GSOD2022 API documentation]] will document, it would be cool to insure we never break the API |
| − | * Add tests to prevent URLs from breaking. | + | *Add tests to prevent URLs from breaking. |
| + | *Measure the coverage of unit tests | ||
| + | |||
| + | === Refactoring=== | ||
| + | |||
| + | * Refactor parts with inlined CSS and JS | ||
* Refactor the routing code: | * Refactor the routing code: | ||
** current routing code is a bit messy (see display.pl) as it does not separate concerns well, and it's very difficult to understand in which function an url will land | ** current routing code is a bit messy (see display.pl) as it does not separate concerns well, and it's very difficult to understand in which function an url will land | ||
| − | ** maybe it could be a good idea to progressively re-implement this part using mojolicious (url by url) | + | **maybe it could be a good idea to progressively re-implement this part using mojolicious (url by url) |
| − | ** refactoring also means adding more documentation | + | **refactoring also means adding more documentation |
| − | * Move taxonomies to their own | + | *Move taxonomies to their own submodule |
| − | * Refactoring our current taxonomy unit tests. Updated taxonomies can make unit tests break easily. We shouldn’t need to change the unit tests each time we update taxonomies. The new tests would work on “concepts”. | + | *Refactoring our current taxonomy unit tests. Updated taxonomies can make unit tests break easily. We shouldn’t need to change the unit tests each time we update taxonomies. The new tests would work on “concepts”. |
* Refactoring ingredient parsing and adding support for nested ingredients and more patterns (so that they can be applied to more languages) | * Refactoring ingredient parsing and adding support for nested ingredients and more patterns (so that they can be applied to more languages) | ||
| − | * Implementing a UI “test – generator” that enables non-programmers to add a test that fails until correction in ingredient analysis is implemented when they stumble upon problems. | + | |
| − | * Show a prompt when the ingredient list photo has changed, but not the ingredient list itself. | + | === Ingredient Analysiis=== |
| − | * Implement more checks and form validation when users enter data (for example nutritional data) | + | |
| − | * Limit the number of times new products without barcodes can be added by a certain IP Address. | + | *Implementing a UI “test – generator” that enables non-programmers to add a test that fails until correction in ingredient analysis is implemented when they stumble upon problems. |
| − | * Implementing autocorrect and spelling checks in the product edit form. | + | *Show a prompt when the ingredient list photo has changed, but not the ingredient list itself. |
| − | * Support for Hindi language | + | *Implement more checks and form validation when users enter data (for example nutritional data) |
| + | *Limit the number of times new products without barcodes can be added by a certain IP Address. | ||
| + | *Implementing autocorrect and spelling checks in the product edit form. | ||
| + | *Support for Hindi language | ||
Latest revision as of 13:49, 23 May 2022
This page is part of Outreachy 2022 it exposes ideas of what tasks could be done as part of the Improve the code quality of the Perl code of the Open Food Facts backend and website project.
Many of the ideas listed below come from the project timelines submitted by Yukti and Raquel.
Documentation
- Extend the existing documentation in POD format
- Document the API in the code (to be coordinated with the GSOD2022 API documentation project)
Make the project accessible to more developers
- improve onboarding documentation
- IDE integration and debugging
- live reload
Code quality
- Investigate and remove Perl warnings during startup and execution
Tests
- Add integrations tests covering the API:
- API is a good entry for integrations tests, it's generally clear what to expect
- As project GSOD2022 API documentation will document, it would be cool to insure we never break the API
- Add tests to prevent URLs from breaking.
- Measure the coverage of unit tests
Refactoring
- Refactor parts with inlined CSS and JS
- Refactor the routing code:
- current routing code is a bit messy (see display.pl) as it does not separate concerns well, and it's very difficult to understand in which function an url will land
- maybe it could be a good idea to progressively re-implement this part using mojolicious (url by url)
- refactoring also means adding more documentation
- Move taxonomies to their own submodule
- Refactoring our current taxonomy unit tests. Updated taxonomies can make unit tests break easily. We shouldn’t need to change the unit tests each time we update taxonomies. The new tests would work on “concepts”.
- Refactoring ingredient parsing and adding support for nested ingredients and more patterns (so that they can be applied to more languages)
Ingredient Analysiis
- Implementing a UI “test – generator” that enables non-programmers to add a test that fails until correction in ingredient analysis is implemented when they stumble upon problems.
- Show a prompt when the ingredient list photo has changed, but not the ingredient list itself.
- Implement more checks and form validation when users enter data (for example nutritional data)
- Limit the number of times new products without barcodes can be added by a certain IP Address.
- Implementing autocorrect and spelling checks in the product edit form.
- Support for Hindi language