That's a fair enough point.
Still, while we should look at it, as with many things, we simply don't have the capacity to do it right now.
I'm willing to try to think through the potential issues there, sure - once we complete issue migration.
Can the DA advise just which command that exists poses a concern that
justifies blocking the endpoint?
No because the issue is not a known command, it is the fact that we don't have the capacity to thoroughly audit the risk profile of every aspect of the API, especially because they have made undocumented changes in the past in new releases.
I know everyone is tired of hearing 'because of capacity' but I'm sorry to say it's the truth.
Credit integration is almost resolved, which means issue migration will be on the table next, and after those two huge aspects of the long running GitLab project complete, we can get some capacity back and triage where to spend it next.
@balsama - A couple of clarifications:
The date that a comment is made is when the attribution was made by an individual (as volunteer, on behalf of employer, or on behalf of client(s) - but the credit does not actually get *granted* until the issue maintainer has selected who should receive the credit, and the issue is closed.
So typically the most accurate date of when credit was granted is status_last_changed, whenever status = [any of the closed statuses],
But maybe in your use case it was important/helpful to know when the attributions were made?
The issue with having date-per-attribution, is that the new system is designed for when we switchover to GitLab issues, and those won't have attributions per individual comment, instead contributors will be able to edit their attribution for the whole issue on the credit record.
hestenet → created an issue.
Corrected survey is being sent! Thanks for the report
Fixed!
Granted @phenaproxima maintainer access and node ownership of the project page. From here he should be able to make any other necessary changes to the project.
Updated to be in a full width section below the other content.
The form is now embedded:
https://new.drupal.org/ai/survey
hestenet → created an issue.
hestenet → created an issue.
hestenet → created an issue.
hestenet → created an issue.
hestenet → created an issue.
lostcarpark → credited hestenet → .
larowlan → credited hestenet → .
I'm going to temporarily direct that CTA to: https://www.drupal.org/project/drupal/#project-releases →
And then we can come back here and decide what the best destination for that CTA should be. (Maybe, as suggested in the summary, we can get the #anchor link to properly display the Core tab at the top).
Adjusting the issue title here to reflect that it is becoming the 'meta' issue for the shared hosting question in general - and start collecting related issues.
Merging back in a discussion from [#3528683#comment-16175309] which I think better belongs here...
As is clearly stated in the issue summary by @pameela, there are still a lot of unknowns here, but I think we can specify the ideal case:
We know we want:
- to allow users to install, maintain, and update DrupalCMS with as minimal interaction with command line as possible
- to move to a model where DrupalCMS is foundational, and site templates become the building blocks applied to kick-start specific use cases
- to offer site templates that 'ship with'(whatever that will technically mean, not fully defined) with DrupalCMS
- to have site templates be easily discoverable in the long term
We also want to avoid:
- Leaving behind components in the codebase that are unused, but are still included as dependencies in composer.json because they can prevent site updates
There's some positive progress because recipe unpacking is done automatically as of 1.2.0, however, if unneeded dependencies are left behind they may still need to be composer remove such-and-such to clear the way for an update.
So, as @pameela has said, we still have the power to define what 'shipping with' site templates means on a technical level, in order to meet all these constraints, and still be transparent to the user
I think right now the issue that solves the unused-but-blocking dependencies but allows us to make a transparent installation process for the user is:
Are there other related issues we should gather here and/or create?
If one of the stated Drupal CMS goals is to limit the amount of command line interaction that site owners *have* to do then I do agree with @catch that it would be ideal to do a version of what @pameela is proposing in comment #3/#4.
The recipe unpacking process helps, but I share @catch's worry about DrupalCMS users getting 'stuck' when it comes time to update.
It sounds like the ongoing discussion for how best to solve this will continue in: 🌱 [META] Integrate site templates into Drupal CMS Active
hestenet → created an issue.
xjm → credited hestenet → .
hestenet → created an issue.
hestenet → created an issue.
hestenet → created an issue. See original summary → .
Going to try moving this to the parent /project/ai and see if it can find the right home from there.
lostcarpark → credited hestenet → .
@mpotter - a staff engineer at GitLab chimed in about 11 months ago to say they didn't think it would be too difficult to add, but it seems to have stalled out from there.
I think it wouldn't hurt to leave a comment to +1
https://gitlab.com/gitlab-org/gitlab/-/issues/217206#note_1941172559
@bertboerland is correct that it is not necessarily 'fair use' to use any kind of trademark without permission of the organization. However, in many cases brands will implicitly allow this in the case of demonstrating integrations or support. The most common example is the use of logos/trademarks when showing if software can be hosted on a particular hosting provider, for example.
After some legal consultation and research - we were recommended that generally speaking most third party technology providers will allow and may even encourage use of a logo to indicate that integrations are available, so long as they are *not* made to appear official. With the extra text on this page we think this should be okay.
However, if we receive a request directly from any of these trademark holders we would absolutely comply with their wishes.
Furthermore - this page will likely be replaced with the new.d.o redesign anyway
I'm going to wont-fix this particular issue for the moment.
hestenet → created an issue.
hestenet → created an issue.
smustgrave → credited hestenet → .
nicxvan → credited hestenet → .
Comments #11 and #12 offer good suggestions about places to make things more visible.
And yes - GitLab does present the git terms of service when they need to accept that - but it's a good point that it can be quite a long time since the last time someone looked at it.
We can probably slightly update the language on: https://www.drupal.org/drupal-security-team/security-advisory-process-an... → (or a related page) with a very simple statement about the security team's discretion to revoke based on the requirement for co-operation.
hestenet → created an issue.
Added more specifics about case study weight
hestenet → created an issue.
hestenet → created an issue.
hestenet → created an issue.
hestenet → created an issue.
rachel_norfolk → credited hestenet → .
Assigning credit. Thank you for preparing the issue!
Assigning credit. Thank you for preparing the issue!
Assigning credit. Thank you for preparing the issue!
Assigning credit. Thank you for preparing the issue!
hestenet → created an issue.
hestenet → created an issue.
hestenet → created an issue.
hestenet → created an issue.
Thanks for gathering all these together @ressa.
This will be postponed until Planet Drupal is ported over to the new site (don't want to invest time on the old site) - and then we will need to do a review and triage of these issues to see which make sense for the majority of planet drupal users.
mradcliffe → credited hestenet → .
jurgenhaas → credited hestenet → .
Could you provide draft changes in a Google doc or similar? I could give you direct edit access as well, I suppose, and we have revision history - I'd just like to be able to easily track what changes we're making. (Though, as you say, this page is pretty out of date).
hestenet → created an issue.
matthews → credited hestenet → .
hestenet → created an issue.
griffynh → credited hestenet → .
This charter has been reviewed and accepted by the Drupal Association.
hestenet → made their first commit to this issue’s fork.
mradcliffe → credited hestenet → .
hestenet → created an issue.
hestenet → created an issue.
I've gone ahead and upgraded @johnpicozzi to have administer maintainers as well so that he can add @murz to assist.
hestenet → created an issue.
mradcliffe → credited hestenet → .
Explanation of how to publish recipes on d.o
Strengthening the escalation process for abuse.
fixing 'enrollment to community tier coming soon' to 'open now'
hestenet → created an issue.
hestenet → created an issue.
hestenet → created an issue.
hestenet → created an issue.
avpaderno → credited hestenet → .