Add draft PR guidelines to CONTRIBUTING.md

[laeubi]

Clarifies expectations for draft pull requests including:

• What draft status means (seeking feedback, work in progress)
• What it does NOT mean (not a shield from comments)
• Requirements even for drafts (clear intent, understandable changes)
• When to convert to regular PR

There where recently some examples for this e.g.

• [WIP] Proper selection coloring in JFace Structured Viewers eclipse.platform.ui#3659
• Sharp rendering of SVGs passed as InputStream eclipse.platform.swt#2935
• Migrate org.eclipse.ui.tests.navigator from JUnit 4 to JUnit 5 eclipse.platform.ui#3500

And it feels it would be good to have a reference for the future with clear guidance.

[merks]

I totally agree with the premise being outlined. When a PR is created it should be comprehensible what the purpose is, not a private working area.

[merks]

Please start new sentence on new lines. Applies to all things below as well. For a bullets use

- This is is a bullet.
  This the second sentence in the same bullet.

[merks]

No need for italics e.g.

[vogella]

Looks AI generated, way to long for this purpose. Also weird to have such longisch rules for draft PR and not for regular PR.

Maybe just add a sentence like: "Draft PR indicate that they are WIP or not yet ready to merged but should follow the same quality rules as regular PR and it is OK to give feedback to them."

[vogella]

Looks AI generated, way to long for this purpose. Also weird to have such longisch rules for draft PR and not for regular PR.

Maybe just add a sentence like: "Draft PR indicate that they are WIP or not yet ready to merged but should follow the same quality rules as regular PR and it is OK to give feedback to them."

[HeikoKlare]

Thank you for this proposal. As we discussed offline already, from my point of view this should kind of reflect the expectations for every draft PR (no matter in which repo), but given that we repeatedly had the situation that PRs did not follow these expectations, it's good to have them documented. This is done in an clear and comprehensible way. I only have one comment for a potential improvement.

[HeikoKlare]

It might be helpful to add a sentence that the PR creator should add information in the PR description on what kind of feedback is desired on that specific PR in the current state. Otherwise this description could lead to the assumption that one can expect early feedback for a draft PR, but usually most people will probably ignore draft PRs until they are marked as ready for review.

[laeubi]

see comment

Please add concrete suggestions on changes you want "something like" is not really actionable.

If someone things other sections are not detailed enough they can be improved in separate PRs.

[vogella]

see comment

Please add concrete suggestions on changes you want "something like" is not really actionable.

If someone things other sections are not detailed enough they can be improved in separate PRs.

Feedback was:

Looks AI generated, way to long for this purpose. Also weird to have such longisch rules for draft PR and not for regular PR.

Maybe just add a sentence like: "Draft PR indicate that they are WIP or not yet ready to merged but should follow the same quality rules as regular PR and it is OK to give feedback to them."

[laeubi]

Feedback was

Maybe it was not clear enough, but please add code suggestions (like @merks and @HeikoKlare ) to suggest concrete changes on the text that can be addressed e.g.

• "Looks AI generated" is nothing that can be acted upon (and yes it was done that way as the AI is much better at the grammar and style than me)
• "way to long for this purpose" is maybe debatable in general I think it should be obvious but it actually seems not to be the case if we take the recent examples and I rather like to have a consistent and detailed instruction in one place I can link to instead of reiteration the same points over and over again on many places.

Still if you have concrete proposals to shorten things without making it a generic short sentence that is open to interpretation and don't help people.

A shorter form would be:

#### Draft PRs

**What it means**
- Not ready to merge / shows work in progress
- Shared to get early feedback or help or build verification.

**What it does not mean**
- A request to avoid feedback.
- A replacement for private branches or local work.

**Requirements**
- Clear goal and current state in the description.
- Changes are understandable and reviewable.
- Reasonably coherent scope.

Convert to a regular PR once it is ready for full review.

[HannesWell]

Personally I'm fine with it either way, being it just a short paragraph or a verbose section explaining the details.
Content-wise I fully agree with it. So for me the most important part is to make it clear.

Also weird to have such longisch rules for draft PR and not for regular PR.

If your think that's important the section could also be about PRs in general and have smaller sub-section about drafts and what is different about them and what's not?