This is being worked on.
darren oh → created an issue.
nicxvan → credited darren oh → .
darren oh → created an issue.
darren oh → created an issue.
I don’t think a comment should be considered a contribution subject to the AI policy. I’m not worried about people using AI to express themselves or to improve the tone of their comments. It would only be spam if AI were used to increase the volume of comments rather than to improve their quality.
The CWG and DA have not put together a position on this. The Google doc will serve as a starting point. I will pass it on to the CWG to polish up and turn over to the DA.
I apologize for not updating this issue after the last CWG meeting. We did discuss it, and have action items to set up accounts on alternative platforms and put notices on the old platforms about where to find updates. I think the next steps would be to draft an official policy on selecting communication platforms, and create reports on which platforms we do and do not consider to be safe and reliable. I have created a public Google Doc so the participants in this issue can directly engage in the drafting process. https://docs.google.com/document/d/1E6lEx7wbk5xGDC_eImiPHPAxAevApfrafMo6...
I would like to help maintain this project. I have already created a browser extension → to make it work with Drupal Forge and am currently working on enhancements.
darren oh → created an issue.
Fixed capitalization of Ops Association.
I remember the vetting process. I would not want to bring the previous vetting process back. I think an open vetting process would prevent a backlog from forming. The important thing is for vetted status to be revokable.
I started the Drupal Forge → project to design a marketplace for site templates that rewards collaboration and contribution. Drupal Forge is very close to being a functional marketplace. I would be happy for the Drupal Association to use our work to build an official marketplace for the Drupal community. I hope the Drupal Association adopts the principles we have followed to build Drupal Forge.
- Sellers should be allowed to sell any templates, not just templates they contribute.
- Template contributors should decide who are the featured sellers for their templates.
- We do not sell the right to use templates, but actual functional sites that generate recurring revenue for sellers and contributors.
darren oh → created an issue.
In case anyone else was confused, I proposed that vetted contributors could lose their vetted status.
I propose we reconsider deprecating sandbox projects in light of the use of AI to abuse the system.
- Non-vetted contributors should only be allowed to create sandbox projects.
- A sandbox project should only be promoted to a full project by a vetted contributor.
- A contributor who creates a release without reviewing it should be given a warning.
- A contributor who creates a release without reviewing it after being warned should lose vetted status for a year.
See 📌 Bulk LLM-generated module publishing by bigbabert Active for an example of a contributor using AI to abuse the system multiple times.
Added automatic update and testing tasks.
I propose we reconsider deprecating sandbox projects in light of the use of AI to abuse the system.
- Non-vetted contributors would only be allowed to create sandbox projects.
- A sandbox project could only be promoted to a full project by a vetted contributor.
- A contributor who released a project without reviewing it would lose vetted status for a year.
There is no problem with publishing modules that are not functional as starting points for community contribution. I believe that is what sandbox projects are for. We used to require all projects to start in a sandbox and go through review before becoming a regular project. Now that AI has made it easier for people to create projects we should go back to that process.
Move this page to second from end.
Added a reminder to include project membership in this guide.
Improved grammar, added advise to ask for pay.
Not sure why you think everything else is passing. The 11.x branch is failing. Fixing all the failures that are already in the branch is outside the scope of this issue.
Code quality hasn't changed, which means test failures are not caused by this change.
darren oh → created an issue.
darren oh → created an issue.
darren oh → created an issue.
damienmckenna → credited darren oh → .
darren oh → created an issue.
This is available now at https://www.drupalforge.org/template/drupal-cms-xb
A note about costs: We use Digital Ocean to host demos. Due to the resources required for acceptable performance, we can only run three XB demos on a single Digital Ocean droplet. Each droplet costs $96 per month. We have reduced our standard demo time from six hours to one hour to control costs. Once a Digital Ocean droplet fills up with running demos, new demos take extra long to spin up because a new droplet has to be provisioned. We are working on ways to optimize the process without adding too much to costs.
You can help cover the cost of running the demos by donating at https://opencollective.com/drupalforge.
darren oh → created an issue.
darren oh → created an issue.
volkswagenchick → credited darren oh → .
darren oh → created an issue.
darren oh → created an issue.
Confirmed the fix works.
mradcliffe → credited darren oh → .
mradcliffe → credited darren oh → .
I haven't seen it recently.
I was just made aware of this discussion today. I expect this issue to come up at a Community Working Group meeting in the near future. Speaking for myself, I think a good case has been made for not relying on X/Twitter and Meta for official communications. I also think it is very likely that if we leave those platforms completely bad actors will open accounts in our name and use them maliciously. For that reason I think the Free Software Foundation is wise to recommend that we maintain our presence on those platforms even after we have replaced them with other communication channels.
darren oh → made their first commit to this issue’s fork.
damienmckenna → credited darren oh → .
We found out the DevPanel developers were giving us under-powered containers. This has been fixed and it spun up in 4 minutes in my last test. I'm planning to build an optimized image to reduce launch time further. I appreciate the suggestions for improvement. I’m thinking to keep review for this issue manageable we should make the fewest possible changes to DrupalPod itself until after this is merged in.
darren oh → created an issue.
Hi Randy, thanks for checking it out. Your feedback is appreciated. The configuration is determined by URL parameters.
darren oh → made their first commit to this issue’s fork.
Thanks for the quick turnaround!
volkswagenchick → credited darren oh → .
volkswagenchick → credited darren oh → .
volkswagenchick → credited darren oh → .
Added testing instructions to the PR.
That's the code that runs on GitPod. It does not include the browser extension.
The pull request is on GitHub because I could not find the extension code here. Please point it out to me if I missed it.
Unless there is a plan to remove the Recipe Installer Kit package after installation I don't know what this has to do with the Recipe Installer Kit. However, I did find that, contrary to what I was told by the Drush maintainers, global PHP variables can be set on the command line using the --include
option to include a command file that sets a global variable in its class constructor.
darren oh → created an issue.
darren oh → created an issue.
Please allow someone else to review.
I would have preferred the event subscriber because it works no matter how recipes are applied, but I can make this work.
I'll grant that I did not present the full technical case for this in the description. Core already skips validation during installation. If you look at my code, you will see that the $install_state
global is initialized to an empty array only if it does not exist. There is zero chance that this will break anything. As I explained, without this change the global variable will not exist for command line scripts that run while installation is paused.
darren oh → created an issue.
This report was based on errors I saw on the command line that I did not see in the Drupal CMS installer. It turned out to be because the installer disables recipe validation. So this issue is just about removing duplicate batch jobs.