Clarify the conditions by which a Participant Representative may be appointed

[waynebeaton]

Member Participants have the right to appoint a Participant Representative to every Specification Project that falls under the purview of the Specification Committee.

The intention of a participant representative is to ensure continuity of a member participant's interest. That is, this is a power that a member participant will use to ensure that they have at least one committer on the project to ensure the continued flow of intellectual property grants. If the member participant already has an employee as a committer, then that member participant is considered to already have a participant representative and could not appoint another.

Further, a participant representative becomes a "regular" committer. That is, once appointed, the committer has no special status (if they change employers, for example, they are not automatically retired and--if they are the only committer employed by a particular member participant--that member participant would be able to appoint another participant representative).

[mmilinkov]

I would actually (potentially) disagree with the last paragraph. I know that standard meritocracy rules would say that committer rights are not tied to employment. But those rules were not applied in the appointment of a Participant Representative. I believe that it would be reasonable to say that if a Participant Representative changes employers that they lose their committer rights on the specification project. This is very normal in the specification world.

[waynebeaton]

I don't disagree. What do we want to happen here?

When a committer changes employers, they will require a new working group agreement (and potentially an employer consent). In practice, I expect that only committers who have actively contributed to the project will bother (or be able) to get new agreements in place, meaning that they should (hopefully) have demonstrated sufficient merit to continue on as a committer. My thinking is that we'd want a committer who does all of this to stick around.

A committer who has not contributed to the project (or is disruptive) will be removed using existing the committer retirement process.

(related point) There's an additional constraint in our committer retirement process that a sole participant representative cannot be retired without direct approval of the member participant.

[kwsutter]

Wow, almost a year has passed since this topic was first broached... Is the management of the appointed representative as a committer difficult to manage? Or, has there been a problem or abuse of this process? I know I placed myself on just about every Jakarta Spec project when we were first establishing ourselves. As the projects have matured and my role has changed, I would like the ability to replace myself with someone else from IBM that is more in-tune with the specific Spec project. I've done this in the past without any issues.

But, with this new wording, if there are other IBMers already on the Spec Project, I would no longer be able to do this simple replacement. Instead, I would have to just retire from the project and then have someone else (my replacement) go through the normal karma establishing process to get voted in. This could take some time depending on the current state of a project (might be a lull time to establish karma). And, in the mean time, this project could be missing a rep from the company. Just seems like extra process.

[waynebeaton]

If there are other IBMers already on the spec project, then, by definition, the company has Participant Representatives.

The ability to appoint is mostly about ensuring that there is some continuity of representation in the event that an organization finds themselves without representation.

But the ability to appoint is limited to one at least in part to avoid abuse in the form of stacking a project with committers.

[kwsutter]

But the ability to appoint is limited to one at least in part to avoid abuse in the form of stacking a project with committers.

Replacing an appointed individual with another appointed individual wouldn't stack the deck. It would be a 1-for-1 replacement.

Specific case in point... I am a Committer on the Jakarta Tags project. I was initially appointed as a participant rep, along with Paul Nicolucci (IBM). Paul is now the project lead of this project. Paul has been attempting to get some work done for Jakarta EE 10 and is looking for help with reviewing and approving PRs and Issues. Although he's been trying to get some assistance from the Pages and Faces projects, it's slow going. So, instead of me blindly approving PRs (since I know nothing about Tags), it would be in the project's best interests to replace me with someone more knowledgable. We're in the process of doing this replacement as we speak for Tags (since this wording for EFSP 1.3 is not in place yet).

Also, due to the lack of participation on this Tags project, even attempting to hold a Vote for a new committer to replace me probably wouldn't even get the required minimum of 3 votes...

Maybe this need to replace the initial Participant Reps will eventually go away due to the maturity of the overall working group. But, for now, I think this ability to do the replacement processing is quite helpful.

If we have to move in this direction for EFSP 1.3, I'll live with it. I will probably ensure that I am the proper Participant Rep on all of the various Jakarta spec projects before 1.3 goes final with this wording... ;-) Thanks!

[waynebeaton]

This is a clarification, not a change.

The EFSP 1.2 states:

Member Participants have the right to appoint a Participant Representative to every Specification Project that falls under the purview of the Specification Committee.

I have an answer for the scenario that you describe, but I want to think about it a bit before I respond.

The ability to appoint Participant Representatives is both a solution and a problem. That is, because participating members can appoint folks to a project that may not end up being active participants (but we nonetheless want them to be committers for the intellectual property grants), we may not be able to run normal committer votes. In a regular old open source project, we could just retire inactive committers to mitigate against a blocked vote due to inaction; we don't necessarily want to do that.