I would like to see some guidelines from the steering committee about
some sort of rubber stamping of contribution ideas long before the patch
process. The learning curve of setting up the GWT build and making a
patch is fairly expensive, and it makes sense for the GWT process to accept
or reject idea long before anyone even starts coding a patch. In other
words I am looking for;
1) Anyone submits a idea for a patch.
Where should the idea go?
2) Someone approves or declines the idea.
How does this occur?
3) If the idea is approved the someone creates a patch for the patch
approval process.
This step seems to have gotten all of the attention.
I suppose this could be done on this GWT Contributors group, perhaps with
some special key words in the subject.
In addition I would like to see some general guidelines from the steering
committee about which contribution ideas are generally accepted/declined.
Ie;
Bug fixes with test cases are generally accepted.
New JSE classes in JSE packages are generally accepted.
JSE classes in JSE packages not yet supported by GWT require a passing
vote in the steering committee.
New features require a passing vote in the steering committee, or consensus
between at least 3 maintainers.
I mention all of this because I went through the process of making a
patch, and it got declined.
https://code.google.com/p/google-web-toolkit/issues/detail?id=8954
If you just read the GWT makinggwtbetter.html, you could infer that the
GWT community will generally add anything.
This is NOT the case, and contributors should NOT have to go through the
work of creating a patch to find out
if a contribution idea will be accepted.
Perhaps this is why your seeing a lot of patch requests.
I think the steering committee could save everyone a lot of time by
amending the GWT contribution process with this suggestion.
Maintainers would generally have less scope, and wouldn't need to spend
time discussing if a idea should or should not be accepted,
this would give them more time to accept more patches focusing on the
quality of the code.
Contributors would know long before a patch is in review that the idea was
accepted, saving them from doing work that could get discarded by the GWT
community.
There should also be some mention of how much time it will take for a idea
to be discussed/accepted or rejected. Perhaps one month for discussion and
then a week for a final decision. Also there should be a process for
re-opening a idea, perhaps you would need to wait a year or so before
re-opening a rejected idea.
Without something like this the GWT community is discoursing contribution,
since contributors could think;
Wow after all the work of attempting a contribution, it got shot down, so
why bother contributing in the future.
Cheers,
Scott
--
You received this message because you are subscribed to the Google Groups "GWT
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/00b834dc-6890-4ff0-a26e-9030a5022432%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
