GWT Patch Review Policy & Maintainer list

[Bhaskar Janakiraman]

Hi Folks,

One of the problems with patch reviews is that we don't have a guideline on who reviews patches and how does a patch get final approval. We put together a proposal for patch reviews, and a  list of maintainers for GWT. At the SC meeting this morning, we decided this makes sense and will be moving forward with it. The two relevant documents are here:

Patch Review Policy: https://docs.google.com/document/d/1_dBGeyqwMaLVXZ48VkOWz64bdLBdUeQgsvY8PEcXyMU/edit#

Maintainer List: https://docs.google.com/document/d/1vyncxfuujIJ3L-PBLNM68tfeXRFZ4qDdnWEodblmvRg/edit#heading=h.3v5wd93k00oh

We hope this will help streamline GWT contributions and make the process more efficient. Over time, we hope this will encourage contributors to take ownership and make substantial contributions. 

If you have GWT experience and would like to be a maintainer, please send email to one of Steering Committee members. 

Thanks,

Bhaskar

(On behalf of the GWT Steering Committee)

[Scott Morgan]

    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