I don`t know what to say yet. I see a huge bureaucratic wall. Only conversations, and then patches hang and are not applied. And over time it gets boring.
Fully agreed, except that I think adding more sub-projects means adding more bureaucracy.
The problem is we are not a company, with employees working 9 to 5. So we can't just say, Fridays are patch days, everyone works on patches...
Reality is, each developer contributes whatever time he can (and likes) to afford. That is out of everyone's spare time. In this time each team member is free to choose what they want to work on.
- Of course there are some things that are off limits, like rewriting the entire IDE into c code.
- And of course there are communication, and helping each other.
- And usually also a willingness to prioritize time, if someone contributes... except this one is a bit more complex
...
So in my own example, I became a contributor because I wanted to enhance the Editor. And later I got interested in the debugger too. Those are the things I chose to work on. (Somehow - and to the day I am not sure how it happened - I also ended up with building the Windows releases)
So if I spent time, I prioritize those.
If I see a patch for those 2 topics I try to make time, but
- sometimes I am busy and that takes some weeks before I can do much about it.
- sometimes I miss something
- sometimes there is no straight forward answer, it may not be possible to apply it as it is. Or I do not have the means to test it right away (eg arm debugging / I have no setup to test those)
But then lots of patches are outside those 2 areas. Ideally I could give them the same priority. But that does not always happen.
And sometimes those patches relate to code, that I am not very familiar with, so I am hoping someone else will take it.
Some patches may apply to something were every team member thinks: someone else => problem.
Anyway this describes the general dynamics. The current situation.
This is the starting point.
The question is => how to solve this?
As for the OT => documentation.I can only speak about the Lazarus part, and even there within limits.
From the svn commit log, it looks like quite a few team members have committed changes to docs, but not sure who does do which extend.
The practical thing is:
- To find open issues (i.e. pending patches on mantis) => that is something you could do (assuming there are pending patches, but without that, a new sub-project would not be needed neither).
- Validate them. Are they still applicable. Older issue may have been solved in a different way.
- Then try to get in contact with a team member and find out if it was overlooked, or why it was not picked up. That is a bit more work. Since to start with there is no rule by which to determine who that team member would be.
Anyway, if you have one (or a list of) issue(s) to enquire about, the best place is to go to the mail list.
Not all team members read the forum on a regular base. Post a mail with a subject like "Who knows about LCL TFooBar help?". Give it a bump (repost) after 4 to 5 days, if it did not get a reply the first time).
I can not guarantee how far that will get you. But it should have reasonable chances to get you some response.