The Configurable Items (CI) in our organization are controlled CIs [Any Project Related Artifact (PRA) received from any source, on which the project team does not exercise any control]. For example, documents obtained from the client or reference technical material. Documents of external origin, such as the ISO Standard, SEI CMMI, etc. are controlled and managed.
Any Project Related Artifact (PRA) is created and managed by the project team and the changing of which does not need any explicit change request, for example, Software Configuration Plan, Review Plan, Audit Plans etc. A baselined CI is any PRA that is managed by the project team and changing it needs an explicit change request for example: Project Plan, SRS ( Software Requirements Specifications) etc.
I am the lead responsible for building our Process Asset Library (PAL) and would appreciate guidelines for what could be the mandatory or acceptable criteria by which the baselined CIs would be updated in the PAL for use by other groups in the organization. I feel, it would certainly help if the criteria could be defined so that people in the organization would know the parameters based on which they could help contribute or share best practices, lessons learned, and any other artifacts in the Process Asset Library for use by anyone in the organization.
I really hate to do this to you, but the answer to your question is it depends upon your needs. Your organization has to decide for itself the acceptance criteria for PAL items. The CMMI does not mandate any criteria for accepting input to the PAL.
From a practical standpoint, you want to encourage the practitioners, project teams, and managers to submit everything of use to you for consideration as candidate PAL items. As the lead responsible for building the PAL, you might consider reviewing each submitted item to determine if you want it in the PAL. I always advocate that in addition to providing a template in the PAL for use by the project teams that you also provide an example of how you want the template to be correctly filled out. Providing a good example can be problematic sometimes. So you would have to review each submitted artifact of the completed template to determine if you want to post that as an example in the PAL. Other project related information may need to be sanitized or normalized by you before you post it to the PAL for use by existing or new projects.
If someone wanted to share a best practice or make a process improvement suggestion, then you should have a process in place for allowing someone to submit a process change. Many companies use their established product/project Change Request system as the tool for submitting Process Change Requests.
The Bottom Line is that you should encourage and accept all data, information, and input as candidate PAL items. Then the Software Engineering Process Group (SEPG), Engineering Process Group (EPG), or Process Group (PG) reviews the input for inclusion in the PAL.