Hey.

When viewing the Pull requests page on https://contribute.mautic.org/contributing-to-mautic/developer/code/pull-requests the link to Step 2: Feature? Check the roadmap & Feature Requests in the TOC is broken, despite it working perfectly when viewing the page on https://github.com/mautic/mautic-community-handbook/blob/master/pages/13.contributing/02.developer/01.Code/02.Pull%20requests/docs.md

I looked into it and it turns out the TOC is linking to #step-2-feature-check-the-roadmap--feature-requests, which apparently works fine when viewing the page on GitHub, but apparently in Grav the working link to the section instead becomes #step-2-feature-check-the-roadmap-feature-requests (with only a single - after 'roadmap') and thus causing the TOC link to not work.

To make things even more confusing, I tried generating a TOC with the link from the source code - https://ecotrust-canada.github.io/markdown-toc/ - and according to that, the section link should be #step-2--feature--check-the-roadmap---feature-requests - i.e. with even more extra hyphens than the current link.

Since I don't have a ton of experience with neither Markdown nor Grav - and have no idea how to even test whether the Canada-approved section link works in Grav - I decided to just create a bug report instead. This might be an easy thing to fix, or it might be more complicated, tbh I have no idea.

There's an outdated reference here:

https://contribute.mautic.org/contributing-to-mautic/tester?_gl=1*1in3zx3*_ga*NDQ4MTgzODAxLjE3MDY2MjAyNjQ.*_ga_ZRB8436CFL*MTcwNjcwMTE5MS43LjEuMTcwNjcwMTI3NC4zOC4wLjA.#using-developer-mode

This should refer to the .env file now.

Per the comment in mautic/mautic#9709 (comment) we should update the docs to include instructions for new migrations changing schema introduced in M2 to account for the fact that it was decided that we would not introduce a migration to migrate all signed integers to unsigned because the migration would be massive.

Such migrations should check to see if the other side of the constraint is signed or not (such as the one introduced in #9544). For example, migration Version20210104171005 would need something like this (not tested)

    $categoryIdColumn =  $schema->getTable("{$this->prefix}categories")->getColumn('id');
    if ($categoryIdColumn->getUnsigned()) {
        $this->addSql("ALTER TABLE {$this->prefix}lead_lists ADD category_id INT UNSIGNED DEFAULT NULL");
    } else {
        $this->addSql("ALTER TABLE {$this->prefix}lead_lists ADD category_id INT DEFAULT NULL");
    } 

Starting with Mautic 3.1, Psysh is available for developers. This information is useful to add to Contributing > Developer > Code > Pull Requests https://contribute.mautic.org/contributing-to-mautic/developer/code/pull-requests. More details can be found in this PR: mautic/mautic#6667

While Mautic is an amazing open source project, meetup is fully proprietary and some community members might not feel comfortable feeding it with content. An alternative to meetup is Mobilizon:
"Mobilizon is an open source software for event planning and group management, launched in October 2020 by Framasoft to offer a free alternative to the platforms of GAFAM (Facebook, Meetup.com, EventBrite). Mobilizon gained much visibility in hacker circles relatively fast, but also soon within cultural scene in Europe and more recently in the mainstream IT media."

I am aware that migrating from platforms like meetup is not easy, especially when a community is established there, but given the open source ethos of Mautic I think it would make sense to consider migrating to FLOSS platforms like Mobilizon or something similar.
Just my two cents.

You have to save the form and the description first, and THEN you need to add the fields.

Originally posted by @RCheesley in mautic/Community-Portal#31 (comment)

At present we don't have any info on the handbook about how all the entities in the community work together - teams, working groups, initiatives, tiger teams etc.

The info was shared in my keynote in November and is on mautic.org / on Confluence.

We should add this to the structure section to give an outline of how it all fits together, but also have some references in the How to Contribute section which is more about how to get started, who the key people are to contact, etc.

https://github.com/mautic/mautic-community-handbook/blob/main/pages/15.contributing/06.Writer/docs.md

This page needs updating/consolidating and importantly, removing references to Acquia.

Clicking on Next button on "How is Mautic used?" page, takes me to Code of Conduct in stead of "How can I try Mautic?".

Not sure how the system works but I guess the issue is related to lack of category in that page.

The Mautic Forum link in 'Apply' Section in sub topic 'Google Summer Of Code' is incorrect.

Initial: https://forums.mautic.org/
Update: https://forum.mautic.org/
Check Here

New Subsection Under GSoC

Purpose

This subsection aims to serve as a document for current and past year Google Summer of Code (GSoC) ideas, as well as potential ideas for Google Season of Docs (GSoD) [In Future] . By incorporating this subsection into our documentation, we provide valuable information to newcomers about ongoing and past GSoC projects. Additionally, it serves as a means to showcase our accomplishments in GSoC and potentially GSoD in the future.

Proposed Content

• Current Year GSoC Ideas: A list of project ideas for the current year's GSoC program.
• Past Year GSoC Ideas: A compilation of project ideas from previous years' GSoC editions. [Year Wise]
• Potential GSoD Ideas: Suggestions for projects that could be undertaken in Google Season of Docs. [In Future]

Benefits

• Information Accessibility: Newcomers will have easy access to information regarding ongoing and past GSoC projects, fostering awareness and interest.
• Accomplishment Showcase: By documenting past GSoC projects, we highlight the organization's achievements and contributions to open source development.
• Future Planning: The inclusion of potential GSoD ideas enables us to prepare for future participation in the program and expand our contributions to documentation.

Implementation Plan

1. Documentation Update: Introduce the new subsection within our documentation structure, clearly outlining its purpose and contents. Google Doc Link For Content
2. Regular Updates: Maintain the subsection by updating it with new GSoC ideas each year and revising past ideas as necessary.
3. Promotion and Awareness: Publicize the existence of the subsection to the community, encouraging participation in GSoC and GSoD initiatives.

Additional Suggestions

• Success Stories: Incorporate success stories from past GSoC and GSoD participants to inspire and motivate prospective contributors.

Conclusion

The addition of a GSoC and GSoD subsection to our documentation not only enhances information accessibility but also strengthens our engagement with these valuable programs. By showcasing our involvement and accomplishments, we demonstrate our commitment to fostering open source collaboration and community growth.

We need to update the council page with this information: https://www.mautic.org/mautic-council.