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 → .
Fixed some aliases on published pages.
hestenet → created an issue.
I am going to proceed with the policy change as proposed, given the clarification about what is included in the role and what is not. However, feel free to add additional discussion if desired.
I have sent a formal educational message and warning to the users referenced above and several others who appear to be senior members of the TATA Drupal team.
More maintainership is good, so hopefully they can respond by engaging more senior contributors, and/or starting by having the new folks establish a track record.
@jdleonard - thank you - looks like that page wasn't ready yet - so I've linked directly the trial instead
@krishnarp - the prevailing accessibility best practice for screen readers and keyboard navigation that we've followed for the last decade plus has actually been to make all links load in the same window rather than extra windows. If there is new documented accessibility research about that being different for external links like social links specifically, please let me know.
@poker10 - move the comparison cards to the top, and will make further edits in the child issue - thanks.
@everyone-concerned-with-page scale - you hopefully noticed some iterative, but targeted improvements to header, text, and margins on especially the top level hero components, but in a couple other places as well. My MR for this was merged by fjgarlin on my team this morning. Didn't want to do anything more dramatic, but now any individual component should fully fit on a 13" macbook screen at 100% zoom.