[Geany-Devel] [FT-plugins] Allowing plugins to supply filetype specific functionality

[Lex Trotman]

[...]
> 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