On Mon, Sep 18, 2017 at 06:08:16PM +0200, Radovan Semancik wrote:

On 09/18/2017 05:20 PM, Howard Chu wrote:

...

Radovan Semancik wrote:

...

I would ... if this was a wiki, or github-like pull request and if there was an example of how a good result should look like. But it does not make sense for me to spend few hours just figuring out how to contribute documentation fix.

So you're still saying, it's fine for other people to put in the hours to produce something you benefit from, but it's too much trouble for you to contribute in return. And in the meantime, it's perfectly OK for you to sit back and complain that things haven't been fixed. Got it.

I'm afraid that you haven't got the point. According to my experience people are willing to contribute. I'm willing to contribute. Just the barrier is too high. But the worst thing is that I feel that the barrier could be much lower if there was a bit of will to lower it. But the will is just not there. And I do not see why. It is not 1990s any more. There are ways how to make cooperation easier. Why not use them?

I'm willing to do the work. In fact, I did some work already. Much more than just few hours. I'm just not willing to overcome unreasonable barriers that take a lot of time, do not significantly increase quality of the product and make my future work miserable. I would rather invest that time to make the software better. And that is exactly what I'm going to do.

I'm a bit concerned that a complaint about how contributing a completely new tool to the project might seem not worth the hassle[0] has provoked a thread which has since shifted to problems about general contribution to the project but still revolving around the same arguments whether they transpose well or not, so you end up talking past each other. No disrespect meant, but this is not helping the community or the project (its codebase).

This is a popular project in terms of usage (isn't the library itself installed on a majority of UNIX systems?) that is simultaneously quite complex[1]. It is maintained by a very small team and little in the way of capacity to process existing contributions quickly and attract new ones. Yes, in my eyes, the project needs to grow or it will die eventually - how many subsystems have been marked as 'experimental' for years?.

On Tue, Sep 19, 2017 at 10:54:56AM +0200, Radovan Semancik wrote:

[...] In addition to that github has hooks that can be used to direct the comments directly to the mailing list. The best solution that I have seen is probably in the Apache CXF project where pull request comments are automatically synchronized with bug tracking system comments. There is always a way ... if there is a will.

What I see as a major problem is that there is no will. OpenLDAP project clearly needs major improvement. But there are almost no contributors to improve the project. I'm trying to explain that there may reasons why people are not keen to contribute. But what I see as a response only makes all of this worse. I'm sorry about that. Really sorry.

...

You could still use "format-patch" to send your change requests via E-Mail.

You could still write your letter by hand, put it into envelope and send it by post. But we are usually not doing that these days, are we? I'm quite sure we all know the reasons.

That is not a situation that's pleasant or helpful to you, but just adding another way to contribute is not the silver bullet[2]. There are successful projects that request contributions in way of patches (Linux, PostgreSQL, just to quote the better known), and the IPR policy is dictated by the foundation and unlikely to change, so let's stop complaining about these policies in principle. On the other hand, suggestions to making their implementation better, especially while committing to make it work and help maintain it(!) are AFAIK appreciated.

In terms of that, some of us would like to have a different bug tracking system, if it supports attaching patches to it I guess that's something you'd find a bit more welcoming.

I'd like to improve this, simplify things and make them more transparent if I can and if you want to help, you're welcome as well, but please be constructive, just re-hashing discussions about things that go against fundamental policy[3] and only add more work for questionable benefit does not seem constructive to me. Start small if you don't want the responsibility to maintain things indefinitely, and to give an example, I think merging documentation patches has been quite hassle-free and time to merge quite short.

Ondrej

[0]. And the same arguments apply pretty much everywhere in the OSS world, so while most are completely valid, they might not be entirely fair [1]. Hell, I don't understand half of its codebase after 8 years since I've first been exposed to it [2]. Not to mention that this only increases the workload for people processing the submissions (e.g. how much work will get duplicated) [3]. Some of it AFAIK dictated by how Kurt set it up with the foundation