[...] > My proposition is that people without time or knowledge not contribute to > the development of this enhancement. Of course everyone would be able to > comment on stuff as it is merged back into master, but only those willing to > actively develop the solutions have any kind of strong voice during the > actual development. >
That approach is very likely to produce a commit/merge bomb, a big complex change that only those intimately involved with have looked at, discussed, reviewed or tested. The point of doing development in a branch of the main repo, instead of somebodys own fork, is to make it visible to anyone with a git clone, all they need is `git checkout the_branch; make install` to try stuff out and all the PRs are visible in Geany github to comment on. The idea is to avoid merge bombs by allowing everyone to have their say during development, not at the end when they have a precipitous learning curve about the new feature, and code, and how it might impact (for good or bad) their workflows, and those who developed it have a large investment which, being human, they naturally feel the need to defend. This is the pain that has made it hard to make big changes in Geany already, the intent should be to encourage participation no matter how minor, not avoid it. Then the merge becomes a non-event because everybody has already said their piece, and the typos are fixed. [...] > > Probably opening specific Issues and linking back to #1195 would suffice. > Yep [...] > Yes, but I propose only those willing (interested in the improvement) and > able (able to read and write C code and make patches/PRs against various > forks/branches) should be included in at least the earlier stages. Of course > it doesn't have to be hard and fast, and it's always useful to have a sharp > eye pointing out fundamental issues, but it's counter-productive to debate > which colour the bike shed should be while the structure is being built. Well, it needs to be before the paint is bought, and if people are discouraged to comment on the bikeshed they are less likely to be willing to comment on the smoking nuclear reactor in the background. > >> Sure but many comments will be minor, and I don't think its a good use >> of either the commenter or the PR owners effort when you compare: >> >> 1) the time and effort required to make a comment "typo" and the OP >> making the change as they do other stuff vs >> >> 2) the commenter making another PR and the OP having to then combine >> those. >> > > That's an example of the kind of comments I was hoping to avoid. Either the > person can wait until the changes are committed and then add a commit that > fixes such trivial errors, send a general cleanup patch to pull requester, > or they can wait until the changes are being merged into the master branch > to raise such minor issues (eg. during some kind of code review). The goal > is that if someone makes some large and/or complicated improvement towards > the end goal on a non-master branch, not to bog them down with silly stuff > anyone can fix or mention later when it actually matters. > It matters when its noticed. Telling people to bugger off and come back later when we are more interested is not the way to run open source developments. Just say "thank you" make the typo fix and be glad that people are at least interested enough to read the code, even if its only superficially its another set of eyes, and nothing is forcing them to contribute. You say people making small comments is a disincentive to you, so what is it for the person who has taken the time and effort to actually read your code, noticed something and make a suggestion, only to be told "we are not interested in knowing about OUR error until YOU provide a fix/alternative"? Instant turn off. > To give an example, it's not uncommon for Columban to do a review and then > provide a link to his working branch implementing the changes mentioned, the > way he thinks are best. This is a goal, IMO. > Thats fine if you have a big contribution to make, but its a disincentive for small contributions. > >> >>> >> [...] >>> >>> You can submit PRs to people's PRs, it's easy. >> >> >> I didn't know you could do that, how? You forgot to explain how to do this. Cheers Lex _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel