Regarding curation as @hansfn stated in #17:
I believe Drupal core deserves professional attention to documentation, and perhaps the top N contrib projects too. (Actual N to be decided)
For the rest of contrib the PR review is a fairly decent gate.
This is an interesting proposal and similar ideas have been kicked around among various people. I have submitted a BoF for DrupalCon to discuss the very topic, I encourage everyone to check the BoF schedule for "Improving the drupal.org Developer Experience" and join us there.
Our own ideas are centered around tackling the contrib space first and rearchitect how documentation works there. Essentially move contrib docs into code (as proposed above) and therefore let everyone who can write MarkDown and submit a PR on GitLab be a contributor. Keeping contrib docs in code would also empower maintainers in a big way and encourage them to keep docs in sync with code. Contrib docs in code also opens the door to let the Doxygen mongrel we have scan code and drop API docs into the doc tree, plus employ other automated or AI tools to enrich the docs. Finally, we would have version support in the docs like our friends in Symfony-land have enjoyed for a decade.
As a second stage we think it would be time to rethink and rearchitect core docs.
I agree with @cmlara in #10 and @ressa in #11. GitLab Flavored Markdown (GLFM) represents a decent and for practical purposes complete implementation of CommonMark. As GitLab users the Drupal community is best served by converging on GitLab Flavored Markdown, instead of trying to match the somewhat opaque CommonMark specification.
I will also note that an effort to document contrib projects in situ has been started: https://drupal.slack.com/archives/CGKLP028K/p1703059851634719
And there is some other related internal discussion as well.
All this to say that converging on a known MarkDown specification is going to be vital.
I think the simplest way to reliably achieve this would be to extend your service worker to reach back into your analytics solution and leave an install event there. Since people use very different analytics systems, there is no way to generically code this in the module.
I am not sure use cases are needed. The module page extensibly describes what the module does. PWAs are still complex enough that if you do not understand concepts on the module page there is a good chance that installing this module won't do you much good.
I wish progressive web apps were as simple as flipping a switch, but we are not quite there in my opinion, and it is not this module's or Drupal's fault.
See the proposed resolution for a summary that could work.
ChristophWeber → created an issue.
In another Chrome profile you cannot access the service worker from the first profile, nor the manifest. The module should install new instances though, eventually. Still, it is really hard to keep all profile crosstalk at bay, and the maintainers (almost) certainly do not test your scenario, nor make any claims that it will work.
Try a completely separate browser for your test scenario.
I think version 4 or 3 can work, in that order. Technically the icons all conform, and once a final version is decided this issue can be marked as RTBC.
@roshni27 It is your decision.
ChristophWeber → created an issue.
laura.gates → credited ChristophWeber → .
laura.gates → credited ChristophWeber → .
laura.gates → credited ChristophWeber → .
laura.gates → credited ChristophWeber → .
laura.gates → credited ChristophWeber → .
laura.gates → credited ChristophWeber → .
laura.gates → credited ChristophWeber → .
laura.gates → credited ChristophWeber → .
laura.gates → credited ChristophWeber → .
laura.gates → credited ChristophWeber → .
laura.gates → credited ChristophWeber → .
laura.gates → credited ChristophWeber → .
laura.gates → credited ChristophWeber → .
This looks great, thank you Jaydev Bhatt!
@kbrinner and @shawn_smiley Can this be merged and a D10-ready version of the module rolled out? D9 will be deprecated in a few short months. Thank you.