Problem/Motivation
At the moment we do not have any information that talks about Single Project Promotion. We are asking users if they want to have a single project promotion but if you are a new user this can be confusing as to what exactly are the differences between single project promotion and full promotion.
Solution
Created text that talks about single project promotion and provide a URL to new user to have a better understanding.
Why my project has been asked for single project promotion?
It’s because your project has some good functionality; however, does not follow guidelines for project length and complexity or you do not want to be a full git vetted user and just want your project promoted to a full project.
What is Single Project Promotion?
Single Project Promotion is a stage where you would have a promoted projec that is been review by the community. It would allow you to create releases for only that project. However, you would not be able to created any other new projects and promote them. An example of where someone might see some advantages here is if this is a vendor provided integration and there is no interest in developing other Drupal modules.
What if I want to promote another project?
You would need to go through the normal project application review process. If your module is complex enough the git administrator can give provide you the full git access. If your project does not follow guidelines for project length and complexity, and this is your second project promotion the git administrator can consider giving you the git access to promote your own projects.
What you guys think about this text? This is what I think how the single project promotion works ( so some of this information can be wrong).
Comments
Makes sense, but I think this
Makes sense, but I think this could be made shorter.
Q: What is a single project promotion?
A: If a project is useful but only has few lines of code then git administrators will promote the project for you instead of giving you the git vetted user role. You will only be able to create releases for this one project. If you need to promote another project you will have to create a new project application.
I think we should start a doc page under https://www.drupal.org/node/1011698 so that we can all edit.
@klausi, I have created a
@klausi,
I have created a child page with this information - https://www.drupal.org/node/2505727
Be Connected: Website | Twitter | LinkendIn | GitHub
Cool, thanks! Please improve
Cool, thanks! Please improve the page as you see fit.
another purpose?
Have I been interpreting this incorrectly? I also though a reason for the single project promotion was if someone didn't want the full git vetted role. For example a vendor has a team of developers who have developed a nifty third party solution and want to hook it up to Drupal. They don't care about getting git access, they only want a full project.
But the code should be
But the code should be reviewed at least once before it becomes a supported project on drupal.org (at least with the current policy). If the code was reviewed and approved then they can have the git vetted user role anyway. If the code has vulnerabilities or licensing issues then we set the application to "needs work".
So this is just about short projects. I think we had a discussion once with a group of developers working on one project who of them should get the git vetted user role. I think we can just pick one of them (or the one with most commits/lines of code).
Vendor applications
I think heddn have a point.
I sometime encounters vendor sponsored projects where the person filing the application is obviously just a project manager. Then, when some issue surface, one of the real developers turn up to respond to issue - presumably because the project manager is not a programmer and have no idea about what the issue is about.
Sometimes, the reviewer can engage in a conversation with this class of applicant and figure out who is the lead programmer and give that person the git vetted user role. But it would be much simpler to just demote it to single project promotion by default. If they're not happy about that, they can be tasked with the logistics of changing the identity of the applicant to the lead programmer.
This should also apply to
This should also apply to users accounts that are global organization accounts. This has come up before as well.
Agree with gisle
I completely agree with gisle and yes while reviewing applications we have encountered such kind of applications in past which were posted by PM's of some organizations and application issue were resolved/answered by some other users; where we specifically asked requester's to change applicant.
My first thought on this was
My first thought on this was that it could bog down the application process as people just start putting these applications in on a whim.
However, as I thought about this more deeply I realize that this could stream line the application process. This could lower the barrier to entry to the full project status and then after a user has been maintaining several projects that have gone through the simpler single project promotion process they could go through the whole git vetted user process more quickly.
That would mean the standards for single project promotion would need to be defined if they aren't already.