>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3467856. --> Reported by: [jurgenhaas](https://www.drupal.org/user/168924) >>> <h3>Objective</h3> <p>As the Starshot strategy v1.0 describes, supporting the <a href="https://dri.es/drupal-open-web-manifesto">Open Web</a> is our responsibility. Drupal's <a href="https://www.drupal.org/association/open-web-manifesto">Open Web Manifesto</a> clarifies, that the Open Web is strengthened by every individual&rsquo;s right to choice, privacy, and security. The Open Web must be designed to protect &mdash; not exploit &mdash; personal data and public discourse.</p> <p>The "Starshot Track 8 Privacy and Compliance" is governed by this responsibility. It will deliver the necessary technical implementation but also provide information and advice for other tracks and the whole product to get it right on all levels.</p> <p>This track's outcome should not be perceived as judgement, it's about information and recommendation. Users of Starshot should be able to make their own (risk) assessment and make conscious decisions about privacy and compliance. However, we are not lawyers and do NOT provide legal advice.</p> <p>At the same time, we shouldn't forget to move fast, whatever that means for this track.</p> <h3>Define the key requirements / features for the recipe</h3> <p>This requires research with target persona, agencies and about existing legislation around the world. We will then have to discuss whether several recipes per region will be required, or if a single recipe can deliver a super-set to address global requirements.</p> <p>Keep in mind that data protection and compliance have to deal with many conflicting interests: Marketing, Legal, IT, users and others. At this point, most stakeholders don't even seem to be aware of the implications, so they can't possibly know what they want.</p> <p>Whether a website owner wants to comply with regulations and/or respect the privacy of their users is entirely their decision, not ours. For those who want to, Starshot makes it accessible and easy to do.</p> <p>If the website operator's business model is based on the monetization of user data, the recommendations, sample content, etc. must look thoroughly different.</p> <h4>Research</h4> <p>This can be done by survey, individual interviews and collecting data from trusted sources.</p> <h5>with target persona</h5> <ul> <li>Marketers</li> <li>Other non-Drupal experts who will be tasked to build a website</li> </ul> <p>Other tracks may have the same issue to get a list of contacts to get in touch. Maybe we can share?</p> <h5>with agencies and freelancers</h5> <p>Individuals can be approached directly. A survey can be posted by the DA to make the community aware and hopefully let them respond.</p> <h5>global legislation</h5> <p>Analyse the legislation collected and provided at <a href="https://www.dlapiperdataprotection.com">Data Protection Laws of the World</a>.</p> <h4>Establish review role for other tracks</h4> <p>To ensure privacy and compliance on a Drupal site, this is not only about what to install and configure. It's even more so about what not to install and configure.</p> <p>This applies to all tracks and the Starshot product as such. The following tracks are in particular the candidates for potential overlap:</p> <ul> <li>5 <a href="https://www.drupal.org/project/starshot/issues/3454545">Create "Contact form" recipe</a></li> <li>12 <a href="https://www.drupal.org/project/starshot/issues/3461529">Proposal for Sitewide SEO recipe</a>: Jim Birch from Kanopi and John Doyle from Digital Polygon</li> <li>15 <a href="https://www.drupal.org/project/drupal_cms/issues/3461533">Proposal for media management</a>: Tony Barker from Annertech</li> <li>18 <a href="https://www.drupal.org/project/starshot/issues/3461542">Proposal for analytics</a>: Dharizza Espinach and the team at Evolving Web</li> </ul> <h4>Ongoing site audits</h4> <p>Privacy and compliance is not a feature, it's a process. Therefore, this track needs to provide an answer for ongoing audits as well, not only for the initial site set-up.</p> <h3>Competitive Research</h3> <ul> <li>Describe feature parity</li> <li>How do we differentiate, how is our solution better than others</li> </ul> <h3>Collect, compare and select modules</h3> <p>Which modules can do the job, and what are the feature gaps?</p> <p>Define and drive required user experience improvements to contributed modules.</p> <h3>Build recipe</h3> <ul> <li>Default config</li> <li>Default/sample content</li> </ul> <h4>Acceptance testing</h4> <p>Test that the recipe meets the requirements and expectations of the target persona</p> <h4>Quality/integration tests</h4> <p>Make sure the recipe keeps working</p> <h4>Basic documentation</h4> <ul> <li>End-user</li> <li>The Starshot leader team(s) with dos and don'ts.</li> </ul> <h4>Metadata</h4> <ul> <li>Logo</li> <li>Summary</li> <li>Screenshots</li> </ul> <h3>Next steps</h3> <ul> <li>Discuss, improve and finally agree upon the above scope and guidelines</li> <li>Finalize a super-set "feature" list that provides all required features on a global scale: <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/drupal_cms/-/work_items/3467855" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/drupal_cms/-/work_items/3467855</a></span></li> <li>Run survey A with (selected) Drupal agencies to learn about additional compliance requirements in their countries, and which of the features in the super-set they would want to avoid under all circumstances</li> <li>Run survey B with target persona to learn about their knowledge, preferences and requirements</li> <li>Perform the competitive analysis: <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/drupal_cms/issues/3467980" title="Status: Closed (fixed)">#3467980: Competitive analysis</a></span></li> <li>Finalize the "feature" list</li> <li>Prioritize items on the feature list and decide which ones will go into the initial "release"</li> <li>Provide initial marketing material (value proposition, slides for Dries-note, educational material for other Starshot tracks, the Drupal community in general, and the target audience)</li> <li>To be continued with module selection, implementation, testing and documentation. Detailed planning and task breakdown will be provided later, there's no value in laying that out just now</li> </ul> <h3>Status after the initial track phase</h3> <ul> <li>Went through extensive research on all levels and collected all the experience from working group members coming from 5 well known Drupal agencies in Europe.</li> <li>Conducted interviews with Drupal experts in the UK, New Zealand, Austria, and a few more countries scheduled either during or right after DrupalCon Barcelona. Received very encouraging feedback that's supporting the outlined strategy and scope.</li> <li>Concluded that neither privacy nor compliance are features, they are processes. Processes that are ongoing throughout the whole live-cycle of each website.</li> <li>This track therefore has to deliver recipes, but also a tool for ongoing audits, so that the site owner can always refer back to it to check about the Compliance status.</li> <li>The full roadmap as it stands today is layed out and prioritized in <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/drupal_cms/-/work_items/3467855" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/drupal_cms/-/work_items/3467855</a></span> with links to action items in separate child-issues. A couple of them are marked postponed, just to indicate that we plan to address them later, and focussing on the others for now. The postponed issues will also require some input and maybe even enhancements from the Drupal core maintainers. That should be addressed when time permits.</li> </ul>