Make conforming to the Eclipse UI Guidelines a requirement for participation

[waynebeaton]

Make conforming to the Eclipse UI Guidelines a requirement for participation in the simultaneous release.

I swear that this used to be a requirement, so there may be a discussion somewhere in which we decided to remove there requirement.

Many years ago we added a "Does project conform to UX/UI Guidelines?" checkbox to release records in the PMI. This was not directly associated with the simultaneous release, but does at least suggest that certain members of the community regard this as valuable.

[scottslewis]

On Thu, Aug 21, 2025, 1:13 PM Wayne Beaton ***@***.***> wrote: *waynebeaton* created an issue (eclipse-simrel/.github#58) <#58> Make conforming to the Eclipse UI Guidelines <https://eclipse-platform.github.io/ui-best-practices> a requirement for participation in the simultaneous release. I swear that this used to be a requirement, so there may be a discussion somewhere in which we decided to remove there requirement. Many years ago we added <https://bugs.eclipse.org/bugs/show_bug.cgi?id=506535> a "Does project conform to UX/UI Guidelines?" checkbox to release records in the PMI. This was not directly associated with the simultaneous release, but does at least suggest that certain members of the community regard this as valuable.

Please identify those members that are asking for this as a requirement. Committer members are required to identify themselves in all discussions. —

…

Reply to this email directly, view it on GitHub <#58>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABHB5DJKMYX4MW3KTVNQ7L3OYR7FAVCNFSM6AAAAACEPYYZ56VHI2DSMVQWIX3LMV43ASLTON2WKOZTGM2DGMBVHE2TKMQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[waynebeaton]

Please identify those members that are asking for this as a requirement.
Committer members are required to identify themselves in all discussions.

I included a link to the public issue in which this was discussed.

[scottslewis]

The link was to the issue many years ago.

…

On Thu, Aug 21, 2025, 1:22 PM Wayne Beaton ***@***.***> wrote: *waynebeaton* left a comment (eclipse-simrel/.github#58) <#58 (comment)> Please identify those members that are asking for this as a requirement. Committer members are required to identify themselves in all discussions. I included a link to the public issue in which this was discussed. — Reply to this email directly, view it on GitHub <#58 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABHB5G7DRZLPTNEOW63TW33OYTBPAVCNFSM6AAAAACEPYYZ56VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEMJRHE3DQMZTG4> . You are receiving this because you commented.Message ID: <eclipse-simrel/. ***@***.***>

[waynebeaton]

Scott,

It was not my intention to suggest that I directly represent the current interests of any particular constituency.

Just so that there is no confusion:

• This is a suggestion
• I have expressed this as a community member, daily user, and somebody who cares deeply about the continuing success of the Eclipse IDE
• I am not representing the Eclipse Foundation in this matter
• I have no particular authority in this matter
• As a committer on a project that participates in the simultaneous release, your opinion actually matters.

[scottslewis]

Scott,

* I have no particular authority in this matter

* As a committer on a project that participates in the simultaneous release, your opinion actually matters.

Last I checked, project committers don't have any real say on SR policy (i.e. probably unfunded requirements on all SR projects). Feel free to argue that we do.

I looked at the 2017 issue (a few months ago): https://bugs.eclipse.org/bugs/show_bug.cgi?id=506535

The discussion (between a total of 6 people) seemed to end with an addition to projects.eclipse.org which I assume was done. At that time, it doesn't appear that people were suggesting this as a requirement of SR participation.

What is your argument as a committer, then, as to why more than what was done in 2017 is needed now?

What would be the effects on...say...projects that have totally different user interfaces than those described in a document written > 10 years ago (e.g. web apps, AI, etc)?

Why would more policy-level requirements be a good thing for the current SR projects? Would all the project leads agree? Would they even know?

[merks]

Yes, this looks to be lost in the migration:

https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements/Appendix#Usability

If I recall correctly, the lack of good non-wiki links seemed a barrier and the fact that no one enforces it make it seem more of a "motherhood and apple pie" are good thing. I'm not sure the documented you linked existed at that time.

In the end, the Planning Council decides on the rules, but all opinions are welcome.

---

Note that there were a long list of "should" rules that are basically not the same as "must" rules. And the latter included things like "Projects should use ICU4J" where the use of icu4j has been dramatically scaled back. Also there were many things that just boiled down to follow the EDP and properly provide vetted IP...

A link to the UI guideline would be seem a good thing to add with the recommendation that that project should follow them.

[merks]

@scottslewis

One reason this issue surfaced is that the placement of a menu item to the right of Help seems surprising/questionable:

See the following for more UX details on the Copilot topic:

eclipse-packaging/packages#344 (comment)

[ewillink]

The "Eclipse UI Guidelines" are guidelines; good principles not mandatory requirements. Enforcing them is clearly impossible. Has any project ever failed a review, and if it did how could a respin to exclude from SimRel happen quickly enough?

My projects are mostly slave projects in that their UX comes from Xtext or platform widgets or WindowBuilder. I think I read the guidelines about ten years ago; good in principle, but I was concerned that not even the platform was genuinely compliant.

Anyway, for my projects an accurate answer to UX compliance might be "in so far as practical". Is that "yes", "no" or "not applicable"? ("Not verified" begs the question of how long a positive verification lasts before re-verification is required.)

[merks]

I've made a simple concrete proposal so that we don't spin off into the woods. I have no plans to enforce this as a must-do rule nor even to check for conformance to the guidelines. A link to the recommendations can only be a good thing and that is the only purpose here.

[scottslewis]

@scottslewis

One reason this issue surfaced is that the placement of a menu item to the right of Help seems surprising/questionable:

> See the following for more UX details on the Copilot topic: > > [eclipse-packaging/packages#344 (comment)](https://github.com/eclipse-packaging/packages/issues/344#issuecomment-3200946185)

Ok. If this is the primary reason behind this issue, making the Eclipse UI Guidelines a requirement for participation seems to me a real overreaction...governance wise.

Especially since at one time for this community there was something about being community/committer/innovation/project-driven as opposed to planning-council controlled.

In the end, the Planning Council decides on the rules, but all opinions are welcome.

Welcome how?

[waynebeaton]

Has any project ever failed a review

No projects have ever failed a review a result of conforming or not conforming to any UI guidelines. EDP reviews are entirely concerned validating that the project is operating in accordance with EDP (the open source rules of engagement in particular), the specification process (when it applies), the IP Policy, and the Security Policy.

The means by which validation that a project conforms to whatever rules the planning council sets out for participation in the simultaneous release, and deciding what to do when a project is offside, is a planning council matter. The EMO would only get involved if the grievance handling provision of the EDP is invoked.

Welcome how?

Somebody could, for example, open a completely public issue and invite comment.

[merks]

I expect the council members will read the opinions expressed here and will take them into consideration.

My personal opinion is we don’t need a rule that we won’t actually enforce. We can be guided by the guidelines and that’s good enough. That is the intent of the PR.

If you look carefully at the wiki versus the markdown you’ll see I’ve done some slashing and burning to focus on what’s needed to keep simrel on track. I hope to make further simplifications.

[scottslewis]

I expect the council members will read the opinions expressed here and will take them into consideration.

I'm glad you said that. Here's an opinion:

1. The planning council doesn't represent the interests of all of the participating project teams or their consumers.

2. The planning council is functionally obsolete as a multi-project coordination mechanism. Most of the operational procedures are well-trodden/understood, well-documented, and in many cases automated.

If this opinion needs another issue to meet expectations/procedures I'm happy to open it.