Beginners Tasks and Developement Transparency

[fweik]

It maybe helpful to get new (potential) contributors started to mark some suitable issues as potential tasks for new developers. I think identifying such tasks and writing them down could also be beneficial for the project as a whole.

Also I think the development process would be easier to follow if for every project there would be an issue which says what is planned and who is working on it. This would also provide a place to discuss design and implementation before time has been
sunk in an implementation. Ideally the first step any workflow would be to open an issue describing what you want to do. Then
agreement if and what to do next can be reached before next steps are undertaken. This would also serve as a huge information
resource, which also, other than documentation, contains information about routes not taken.

Both of these things are common in open source projects.

[jngrad]

We've discussed a similar topic recently in the core team. We thought about using a Kanban-like solution or GitHub Projects.

Then agreement if and what to do next can be reached before next steps are undertaken. This would also serve as a huge information resource, which also, other than documentation, contains information about routes not taken.

I'm doing this for medium-sized projects that are self-contained, see e.g. #3977 #3883. Larger projects like kernel refactoring could benefit from that too.

[fweik]

I've noticed that you are doing this, and I find this very positive.

We've discussed a similar topic recently in the core team. We thought about using a Kanban-like solution or GitHub Projects.

I think for starters it's more important that stuff is written down, and not how. You first have to have the issues before they need
to be organized. Then, I think GitHub Projects does the job: you can use that as Kanban board, the columns are customizable and it has integration with issues/PRs out of the box.

[jngrad]

Tickets are now often written with background information, implementation details, minimal working examples and links to related tickets and external resources like the CMake documentation or the C++ standard. Low-hanging fruits are systematically labeled CodingDay. External contributors who join our remote coding days on Zoom can quickly find suitable tasks by selecting a ticket category like waLBerla or a Github project like Reaction Methods.