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.

[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.

[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?

[laeubi]

Merging this PR to establish clear draft PR guidelines.

Reason: We're seeing recurring cases where draft PRs lack sufficient context for reviewers to understand the intent and changes (most recent example: eclipse-pde/eclipse.pde#2204 - draft PR with title "Classpath computation" but no description). This makes it difficult for maintainers to provide meaningful feedback or assess the direction, even for work-in-progress.

The guidelines clarify:

• Drafts are welcome for early feedback and WIP
• But they still need clear intent and understandable changes
• They're not shields from review comments

This gives us a clear reference for future situations and helps contributors set expectations correctly, if anyone feels we need adjustments to this or other sections feel free to propose one.