Dave Clements has moved on to Anaconda to find a new challenge.
Thanks so much for the countless things you've done @tnabtaf, you know
the Galaxy community wouldn't be what it is without you!
Oleg has done so much awesome stuff for us, but he's moved on to
Industry. Thanks for all your brilliant work @OlegZharkov, and hope to
see you around.
David has taken on the migration to fastAPI as his first big project
within the Galaxy codebase and has gained a very good understanding of
Galaxy's backend and the new server stack. His PRs are well-crafted and
contain rigorous tests.
David is also the maintainer of the [Galaxy language
server](https://github.com/galaxyproject/galaxy-language-server), has
presented his work at this years' GCC and is a member of the backend
working group. So I'm proposing to add David to the committers group.
Oleg has contributed many large pieces of new and modernized frontend
components as well as complementary backend changes. He has included
many tests for new and old components, is an important member of the
UI-UX and testing working groups and has presented his work at multiple
GCC conferences. So let's make Oleg an official member of the committers
group.
Sergey Golitsynskiy has been a very active contributor to the Galaxy
code base and ecosystem (ansible-galaxy, sequence-utils, iuc) during the
last year. His contributions are of high quality and contain appropriate
tests and documentation and it is a pleasure to review Sergey's
contributions.
I propose that we add Sergey to the Galaxy committers group so that we
can benefit from his experience and skills.
Use 'kind/refactoring' for refactoring AND any kind of code cleanup. The
'area/cleanup' is removed as redundant and not really describing a
"focus area" or "domain" (as per description of area labels).
There's a considerable amount of work done on Galaxy's configuration
system, from definition in the schema to loading and processing
configuration options, to handling configuration files. Currently, there
is no easy way to tag this: the "area" label that has been used is
"admin", but I don't think that's correct: modifying how configuration
is processed by the system is very different from how it is utilized by
the user.
I realize that would add yet another option when tagging an issue or PR,
but I think the benefit of accurately tagging that work outweighs a
little bit of added complexity. I'll be happy to retag relevant issues and
PRs (for the past several months or even 2019, maybe?) if this is approved.
- Add some labels that were added on GitHub, but not here:
- authentication
- client-build
- compliance
- Rename `system` to `scripts`, since this was the original (I think)
and `system` is too generic
- Remove unused `roadmap`, we use GitHub `Projects` now
- Add some labels that have been added to Github but not this list (tool-dependencies, i18n, security).
- Add subworkflows which was added to Github as ``area/subworkflows`` but which I think should be ``area/workflows/subworkflows``.
- Add various specific testing areas (integration, selenium, and api) and a general testing area for bugs and enhancements for other parts of testing.*
- Add labels I think should be there but aren't (cwl, objectstore, upload, webhooks)
* I know there is a kind/testing, but I initially thought it should be an area and I still do. I'm either making enhancements or bug fixes to testing - I think ``kind/bug``, ``kind/enhancement``, and ``kind/refactoring`` apply to the ``area`` of testing. Maybe the new more specific areas for testing make that clear? I wanted to see all the recent Selenium changes but I didn't have a real clear way to do that without this. Maybe a compromise if others haven't come around to my way of seeing things is to keep the area sub-types of testing (e.g. ``area/testing/selenium``) but drop ``area/testing`` from this list.
Dannon