Community
Participate
Working Groups
The Committer portal is confusing to relatively new committers like myself. Particularly I would suggest a revamp of the CQ submission process that is more descriptive and enforcing of a workflow. Something like a *TurboTax* workflow/wizard with questions and explanations of options might be one approach. The current descriptions and options can lead a new user to erroneous inputs. Also aiding the process as it goes through bugzilla would be helpful. Let me share one experience that I had in this regard: I was a little confused on my first CQ, when the IP rep. said that I needed a PMC to declare a dependency relationship...and I asked myself "and how am I supposed to obtain that?" I didn't realize that I needed to trigger that as a conversation in the dev channel. Nor did I know what to say. All of that kind of ambiguity makes the process difficult for new people. The current bugzilla configuration is not adequate for that....we need something that can enforce and describe the workflow better.
We have an opportunity to do a better job of this with the new project managment infrastructure.
There are several different paths through the workflow. Code contributions to the project, including the initial contribution, that are to be maintained in an eclipse.org SCM may require a CQ. The determination of whether or not a CQ is required is defined in the IP Due Diligence poster [1]. I hesitate to implement the decision process as it is subject to change, and my sense is that it would require a lot of time (both the initial implementation and maintenance). Still, we can do better than what we do today by including a few words and a pointer to the process poster. Third-party libraries [2] come in different flavours. Non-exempt pre-req libraries are the most common. They always require a CQ, but--in cases where the library has already been approved for use by another project--a piggyback CQ is used. The current workflow for this is relatively simple and I believe that we should use it as the starting point for a new implementation. We can do better this time around by providing helpful text/instructions. The source code for Non-exempt pre-req libraries must be attached to the CQ. This step is performed directly against IPZilla after the CQ is created. At this point in time, I don't see any value in changing this. Again, however, I think that we can probably provide better help here to make sure that the committer understands the workflow. A diagram might be handy. Exempt pre-reqs and works-with dependencies also require a CQ, but without the attachment of source code. The requirement to mark the CQ as an exempt pre-req or works-with is noted in a comment by the committer. This state is not indicated (AFAIK) in any field in the record until after the designation is complete (at which time the state of the record is marked as exempt_prereq or workswith. Minimally, we can include the requirement to so-mark the CQ in the initial comment. [1] http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf [2] http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf
Created attachment 215289 [details] The non-exempt pre-req workflow
After a discussion with Wayne yesterday I'm going to start working on this feature by implementing the following: Committers will be greeted with a multi-step wizard like form, that will do a better job of sorting the user before reaching IPZilla. We'll be linking to the IP Workflow Chart on the first page to ensure that people have seen it, then we'll go about determining the correct path. Users will then be asked to search CQs to ensure this isn't being re-filed. An IPzilla module will need to be built to manage the interaction with IPZilla. We need to be able to use the DB in a read-only state, however actual submissions should still be directed through IPZilla.
Any list of piggyback candidates should indicate a clear preference for Orbit bundles. I recommend displaying distinct lists with the Orbit list on top surrounded by lots of helpful text.
I've been working on this multstep form now and its close to completion of the workflow. At this point however I don't do anything interesting with the data collected. My next step will be to verify that the information collected and prepare the query for submission to IPZilla. However I'm wondering if it would be helpful to save a copy of the form values so that we could track requests should there be problems during testing. Thoughts?
(In reply to comment #6) > However I'm wondering if it would be helpful to save a copy of the form values > so that we could track requests should there be problems during testing. > Thoughts? That might be handy for auditing purposes as well. Is there a downside?
Should Sharon and Janet be in on this for feedback?
(In reply to comment #8) > Should Sharon and Janet be in on this for feedback? I've been talking with Sharon as I go with questions about this but CC'ing them wouldn't hurt.
FYI, I've opened bug 300717 a while ago. Library update CQs for us Orbiters can be easier. Would be great to incorporate this as well.
With some final tests the IPzilla module for PMI should be ready to go. At this point the IPzilla test site is ready to accept some "real" CQs once those pass we'll need to discuss when an idea roll-out date for this is. I could use a few committers entering copies of their CQs into the test system as a way to sanity check our results.
I noticed the links on the live PMI site today. Is this LIVE now, i.e. can we use it for creating real CQs?
(In reply to comment #12) > I noticed the links on the live PMI site today. Is this LIVE now, i.e. can > we use it for creating real CQs? Yes this change is live. Feel free to log CQs using that method now. I plan on making more a fuss about it once Kepler has passed.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
(In reply to Nathan Gervais from comment #13) > (In reply to comment #12) > > I noticed the links on the live PMI site today. Is this LIVE now, i.e. can > > we use it for creating real CQs? > > Yes this change is live. Feel free to log CQs using that method now. I > plan on making more a fuss about it once Kepler has passed. Wayne, I assume we are done here?
(In reply to Christopher Guindon from comment #15) > Wayne, I assume we are done here? Yup. Though, I do have a few issues that I'd like to address. But I'll open new bugs to address them.
