[liblouis-liblouisxml] Re: Drive-by table contributions
- From: James Teh <jamie@xxxxxxxxxxxx>
- To: liblouis-liblouisxml@xxxxxxxxxxxxx
- Date: Tue, 07 Oct 2014 16:19:33 +1000
Hi Christian,
Thanks for your explanation and thoughts. Comments inline:
On 4/10/2014 12:49 AM, Christian Egli wrote:
Also as you might know a lot of our table contributors are not
developers, they do not hang out on our mailing list, so they submit and
disappear, which often leaves us with the choice of taking something
as-is or forgetting about it.
That is unfortunately all too common for any open source project.
However, that still doesn't mean it has to be accepted as is. One
further choice is for another active contributor (time permitting) to
work with the contributor directly to resolve the problems.
With the Indian tables it seems to be a little bit more complicated. I
realized that they had problems (`lou_checktable` complained) and tried
to fix them with the submitter. I sunk a lot of time into these tables,
fixed the apparent issue and even talked to their manager over skype who
assured me that they were a) from a braille authority, b) had tested
their tables manually and c) were going to submit test data for the
harness. Having spent so much time on these tables I wanted them off my
mind and so I included them. Only after the bug report I found out about
the duplication and luckily Peter provided a patch for this.
Since you did try to scrutinise the tables and work with the submitter,
I guess the only further thing that could have been done was more
scrutiny. Of course, there's a limit to the time any of us have for
reviewing submissions, so I understand things like this can and will
slip through.
So what do we learn from this? I don't know unfortunately. I guess you
are right that we can be more patient with including things as we
release every 3 months. On the other hand there are always going to be
table contributors who will not work to our standards. What do we do
then? Just let the table rot away in a branch or a pull request?
I think it could go something like this:
1. Some effort needs to be made to contact the contributor to point out
the problems.
2. Time permitting, perhaps a maintainer might be able to work with the
contributor to fix them.
3. If the contributor refuses to cooperate, they can be left to rot.
Perhaps someone else from the community who cares about said tables and
thinks there is something worth salvaging will step in.
How do handle drive-by
submitters in NVDA?
In a similar way to that described above. Unfortunately, I don't do as
much code review as I should, so some patches don't get addressed as
quickly as I'd like. However, the key point is that in general, nothing
from an external contributor gets into NVDA unless it has been
thoroughly reviewed and all outstanding review issues have been fixed,
whether by the contributor or someone else (usually Mick or me).
Thanks,
Jamie
--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: jamie@xxxxxxxxxxxx
For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com
Other related posts:
