Talking about project management, I am trying to understand if you don't plan to implement it soon as you just said, shouldn't you be monitoring this issue - since you are interested in it - instead of having it being assigned to you?
Yes you have a point there. I just detached myself from the issue.
Since tickets are already assigned, how other volunteers can realize when their help is needed or not? When their help will be accepted or not? When tickets are already being worked on or being on hold?
Tickets belonging to a certain subsystem are often assigned directly to its maintainer either automatically, by himself or by somebody else.
It means CodeTools to Mattias, debugger to Martin, Delphi converter to me etc.
If a ticket has been there for a long time untouched, it is very likely not being worked on. You can solve such an issue but please communicate about it, too. Mails to Lazarus mailing list or to the developer directly are easy to send and are always read.
Ok, the issue in question did not belong to any specific subsystem. I planned to implement it, clicked "Assign" button but then other priorities came up. It happens.
I am trying to help more, but how Lazarus and FPC are internally developed, how decisions are made, when patches are applied or rejected, how funds for complex or not attractive activities are raised,
This is a volunteer open source project. Lazarus project has no paid developers so far. The foundation funded the Pas2Js thing and has further plans. Let's see what comes out of it.
When patches are applied or rejected? Good patches are applied and bad patches are rejected.
How decisions are made? Hmmm... Everybody scratches his own itch.
Some issues are even discussed in mailing lists.
and why contributing members are expelled are a puzzle (very confusing) for me.
Do you mean that some patches get ignored for a long time? Yes, it is annoying for a contributor. However the situation has improved. The goal is to accept or reject a patch in a reasonable time. The downside is that some patches have very low quality. They either break things or they fail to understand the code's design and mess it.
I have got feedback for applying poor and invalid patches. True, but it is impossible to study every patch as deeply as would be needed. It means a contributor has responsibility for the quality of his patch. He must study the code and ask from others when needed. Otherwise nobody wants to apply the patches and there will be again lots of them ignored.
Anyway, when somebody provides many high quality patches, he gets a high reputation and finally commit rights for SVN. That has happened to every current Lazarus developer at some point!
valdir.marcos, I don't remember your patches. Were they good or crappy?
No need to wait, just take an issue you want to solve and then solve it. First let others know you are doing it, so there is no danger of duplicate work.
No "official" committee is going to assign tasks for you. Just bite the bullet, dive into the code and fix it.