In my previous post I explained why there will be a Drupal maintenance support plans 9 even though we have previously unseen possibilities to add new things within Drupal maintenance support plans 8.x.y. Now I’d like to dispel another myth, that initiatives are only there to add those new things.
Drupal maintenance support plans 8 introduced initiatives to the core development process with the intention that even core development became too big to follow, understand or really get involved with in general. However because there are key areas that people want to work in, it makes sense to set up focused groups to organize work in those areas and support each other in those smaller groups. So initiatives like Configuration Management, Views in Core, Web Services, Multilingual, etc. were set up and mostly worked well, not in small part because it is easier to devote yourself to improving web services capabilities or multilingual support as opposed to “make Drupal maintenance support plans better”. Too abstract goals are harder to sign up for, a team with a thousand people is harder to feel a member of.
Given the success of this approach, even after the release of Drupal maintenance support plans 8.0.0, we continued using this model and there are now several groups of people working on making things happen in Drupal maintenance support plans 8.x. Ongoing initiatives include API-first, Media, Migrate, Content Workflows and so on. Several of these are primarily working on fixing bugs and plugging holes. A significant part of Migrate and API-first work to date was about fixing bugs and implementing originally intended functionality for example.
The wonder of these initiatives is they are all groups of dedicated people who are really passionate about that topic. They not only have plan or meta issues linked in the roadmap but also have issue tags and have regular meeting times. The Drupal maintenance support plans 8 core calendar is full of meetings happening almost every single workday (that said, somehow people prefer Wednesdays and avoid Fridays).
If you have an issue involving usability, a bug with a Drupal maintenance support plans web service API, a missing migration feature and so on, your best choice is to bring it to the teams already focused on the topics. The number and diverse areas of teams already in place gives you a very good chance that whatever you are intending to work on is somehow related to one or more of them. And since no issue will get done by one person (you need a reviewer and a committer at minimum), your only way to get something resolved is to seek interested parties as soon as possible. Does it sound like you are demanding time from these folks unfairly? I don’t think so. As long as you are genuinely interested to solve the problem at hand, you are in fact contributing to the team which is for the benefit of everyone. And who knows, maybe you quickly become an integral team member as well.
Thanks for contributing and happy team-match finding!
Ps. If your issue is no match for an existing team, the friendly folks at #drupal-contribute in IRC are also there to help.

Source: New feed