As a new contributor, I wanted to add my two cents. I've submitted a
minor amount of patches (somewhere between 1 and 3, I can't remember
exactly), and I feel that the other problems you raise, primarily the
first one, are obstacles towards that though. Patches like that are
obviously minor, since they aren't fixing bugs, so they're low priority.
That drags out the process though, and it's a little discouraging to
submit patches that don't receive responses, and make me less eager to
submit more.For example, I submitted a tiny refactoring patch last month
that hasn't received an answer yet. I'm not looking for special
treatment of course, and think that review of patches is super important
(especially for a new contributor like me)
I think that the solutions you raise are great starts. I feel like the
documentation that I've used has been pretty accurate, but it could
always be better, and someone who is the point person for dealing with
people like me would be a good idea. I would not like to volunteer for
that myself. I don't feel comfortable enough with my abilities, or my
experience with the community, to able to help others or give reasonable
answers for patches other than something like "yes, I've seen this". I
will try to help out more with verifying bugs though.
On a side note, I'd like some guidance though on whether or not the
community is interested in a refactoring project (done in pieces of
course). I'm wondering if I should be attempting to submit minor (or
larger) patches moving things around to make it easier to maintain, if
there is a way to go about this (since submitting a bunch at a time,
breaking them up, etc), certain things I should focus on or ignore, etc.
I haven't done much since that mostly because work has consumed my free
time, but I'm going to have a significant amount more free time starting
in the next week or so, so I'm looking for somewhere to direct my energies!
On 4/25/21 12:30 AM, Bastien wrote:
Dear Timothy,
thanks for raising this points so carefully, they are important.
I see three distinct problems:
1. The lack of response and/or follow-up when people contribute by
sending bug reports or patches on the list.
2. The lack of maintainance on documenting the contribution process
and the correct expectations for future contributors.
3. The inherent difficulty to move the Org codebase forward.
I won't comment on (3). For (1) and (2), I suggest appointing a
"contributor steward" with these responsibilities:
1. Maintain updates.orgmode.org (i.e. make sure it is accurate.)
2. Maintain the documentation for contributors.
3. Help contributors enhancing their patches.
4. Try to reproduce bugs (and confirm them for updates.orgmode.org)
5. Make sure patch contributors are not left with no answer.
You started (1), which is really appreciated.
Tim and others mentioned (2), and that's certainly needed too.
(3) has historically been the role of the maintainer and of the core
contributors, but helping with this is very welcome: knowing the doc
at https://orgmode.org/worg/org-contribute.html by heart, educating
contributors on the commit messages, etc. This all helps.
(4) is perhaps the most daunting task: I even think we could have
someone only dedicated to this very important task. Just count the
number of times Nicolas says "I cannot reproduce this." Each time,
there is a real bug that is *not* fixed...
(5) is not about systematically welcome patch submitters with a
message (that would be annoying) but to monitor updates.orgmode.org
and decide what to do with a patch that didn't receive feedback:
either say thanks and ping the list for why you think the patch
deserves more attention, or thanks and dismiss the patch, or another
answer.
What do you think? Would you be willing to take this role?
If not, that's perfectly okay, I'll send a call for help.
Thanks,
