New documentation page

.github/workflows/python-package.yml

@@ -80,7 +80,7 @@ jobs:
         run: |
           cd docs
           python generate_input_tables.py
-          if git diff -- available-modules/active-modules/*.md | grep .; then
+          if git diff -- modules/dda/*.md modules/dia/*.md | grep .; then
             echo "Error: Input files tables not updated, run: cd docs && python generate_input_tables.py"
             exit 1
           fi

docs/about/faq.md

@@ -0,0 +1,155 @@
+(faq)=
+# Frequently asked questions
+
+The answers to "What is ProteoBench?" and "Who is it for?" are in the section [About](index.md). This page covers
+more specific questions.
+
+## How do I use ProteoBench?
+
+Depending on your goal:
+
+- **Looking for a workflow recommendation?** Open the [module](../modules/index.rst) that matches
+  your data type and application in the web app, and compare which workflow performs best on the metric that
+  matters to you (e.g. quantification accuracy).
+- **Want to compare your own workflow with public benchmark runs?** See [Your First Submission](../your-first-submission/index.md)
+  for the full walkthrough.
+- **Want to run things locally instead of through the web app?** ProteoBench is available as a
+  [PyPI package](https://pypi.org/project/proteobench/); see
+  [Using ProteoBench locally](../contributing/local-usage.md) for a runnable example notebook.
+
+## Why does my upload fail?
+
+Check if you have the correct file uploaded. If the problem persists, please [open a GitHub issue](https://github.com/Proteobench/ProteoBench/issues) including the error message and if possible, the first few rows of the uploaded file.
+
+## Do I need to run my workflow on a predefined dataset?
+
+Yes. Every module defines a fixed benchmark dataset, and all submissions to that module must use
+it. This keeps comparisons fair — differences between submitted results then reflect differences in
+data analysis, not differences in sample composition, instrument setup, or data quality.
+
+If your use case needs a different dataset, [propose a new module](../contributing/propose-a-module.md) —
+ProteoBench is modular by design specifically so it can grow with new use cases.
+
+## Do I need to use the same workflow parameters as other users?
+
+No. You're free to submit results from your own parameter choices. There are only a few exceptions
+such as digestion parameters for the entrapment module, and specific FASTA files for most modules.
+Those exceptions are explicitely mentioned in each module documentation page.
+Every public submission's parameters are collected and downloadable, so others can interpret performance differences
+in light of software version, settings, and search database. If you're deliberately testing
+one specific parameter, mention that in the comments field when you submit.
+
+## Do I need a specific FASTA database?
+
+Where the choice of database affects the benchmark outcome, the module page specifies the required
+or recommended FASTA. Using the same database keeps benchmark runs comparable.
+
+## Can I benchmark commercial software?
+
+Yes, as long as its output can be parsed directly or converted into one of the module's supported
+formats (see that module's "Tool-specific setup" section, or use the
+[custom format](../your-first-submission/index.md#if-your-tool-isnt-supported) if there's no
+parser yet).
+Users and developers are encouraged to contact the ProteoBench developers if they want a
+new parser to be added for a specific software package.
+You can [open an issue] (https://github.com/Proteobench/ProteoBench/issues) or [propose a new parser](../contributing/adding-a-module).
+
+## What should I do if my tool isn't directly supported?
+
+Use the custom tabular format described on the module page — see
+[Your First Submission](../your-first-submission/index.md#if-your-tool-isnt-supported) for what
+that involves. If you'd like native support instead,
+[open an issue](https://github.com/Proteobench/ProteoBench/issues) or
+[propose a new parser](../contributing/adding-a-module).
+
+## Why are submissions reviewed before becoming public?
+
+Manual review is a quality check: it catches incomplete submissions, wrong file types, a mismatched
+module, missing metadata, or results that can't be meaningfully compared to what's already public.
+The submission process is done on GitHub, and you can contact the core ProteoBench team if you have
+ any question and/or wants to provide more information on the benchmark run that you want to make public.
+
+## Does ProteoBench run my workflow automatically?
+
+No — ProteoBench evaluates the output files you upload, it doesn't execute your workflow for you.
+You download the benchmark data, run it through your own software or pipeline locally, and upload
+the resulting files. This is what lets ProteoBench support commercial software, in-house pipelines,
+and tools still under development.
+
+If you want to automate running several open-source search engines (DIA-NN, AlphaDIA, Sage,
+FragPipe, MaxQuant, MetaMorpheus) on ProteoBench benchmark datasets, see
+[ProteoRunners](https://github.com/Proteobench/ProteoRunners), a separate Nextflow pipeline that
+runs them in Docker containers and produces output already structured for ProteoBench submission.
+
+## Where do I find the input data for a module?
+
+Every module page links directly to its raw MS files, search database (where relevant), and any
+example outputs. Some datasets are also mirrored on public repositories such as
+[ProteomeXchange](https://www.proteomexchange.org/). If you can't find what you need,
+[contact us](mailto:proteobench@eubic-ms.org).
+
+## What is epsilon?
+
+Epsilon is the accuracy metric most quantification modules use when the expected abundance ratios
+between conditions are known. For a given precursor, it's the difference between the observed and
+expected log2 fold change between conditions A and B — a value near zero means the workflow
+recovered the expected ratio accurately.
+
+Read epsilon together with the other metrics on the same plot: a workflow that quantifies many
+precursors isn't necessarily the better choice if its epsilon is high.
+
+## Does ProteoBench normalize the data or impute missing values?
+
+No, not for the current modules. Normalization, missing-value handling, transfer steps, protein
+inference, and quantification strategy are all treated as part of the workflow being benchmarked —
+report them in your submission's parameter file. Where ProteoBench itself does perform some
+processing, the relevant module page says so explicitly.
+
+We advise against applying any form of post-processing to the workflow output that you want to
+ submit to ProteoBench. If you do perform post-processing, you should indicate it when you
+  upload your workflow parameters in the Public Submission tab. A check box and a free-text
+   field are present to this effect.
+
+## How do I interpret differences between benchmark runs?
+
+Differences can come from many places: feature detection, spectral library generation,
+identification scoring, FDR control, match between runs, normalization, missing-value handling, and
+software defaults. Treat results as workflow-level comparisons, and check both the software version
+and the submitted parameters before drawing conclusions.
+
+## Does ProteoBench validate FDR independently?
+
+Where appropriate datasets exist, yes — see the entrapment-based modules (e.g.
+[DIA Ion Entrapment - Astral](../modules/dia/entrapment-dia-astral.md)), which add peptides
+into the FASTA that cannot be legitimately identified to estimate the true false discovery
+proportion independent of what the search engine reports.
+
+## How should I read the main plot on a module page?
+
+As decision support, not a ranking. A tool that does well on one module, dataset, or metric may not
+be the best fit for a different instrument, acquisition method, or question. Before drawing a
+conclusion, check the module and dataset, the software version, the submitted parameters (e.g. the
+target FDR), the exact metric definition, and the sensitivity/accuracy trade-off — and consider
+whether the benchmarked workflow resembles your own intended use case.
+
+## How can I follow ProteoBench's development?
+
+- [GitHub Discussions](https://github.com/Proteobench/ProteoBench/discussions) — the preferred
+  place for technical discussion, module proposals, and parser development (needs a GitHub account).
+- "Watch" the [ProteoBench repository](https://github.com/Proteobench/ProteoBench) for email
+  updates on issues, discussions, and releases, or watch an individual
+  [results repository](https://github.com/Proteobench) for a specific module.
+  ![Screenshot showing the "watch" button on GitHub](../_static/img/watch_image.png)
+- No GitHub account? Use the [web app](https://proteobench.cubimed.rub.de/) and
+  [docs](https://proteobench.readthedocs.io/en/stable/) directly, or join the ProteoBench channel
+  on the [EuBIC-MS Slack](https://eubic-ms.org/).
+- Follow [ProteoBench on LinkedIn](https://www.linkedin.com/company/proteobench) for regular
+  updates.
+
+## How can I contribute?
+
+Submitting your own workflow's results is the most common contribution — see
+[Your First Submission](../your-first-submission/index.md). Beyond that, you can report issues,
+improve the documentation, propose a new module, contribute a parser for an unsupported tool, or
+join the discussion. See [Contributing](../contributing/index.md) for the code/module side of
+things, and [contact us](mailto:proteobench@eubic-ms.org) if you want more information.

docs/about/index.md

@@ -0,0 +1,15 @@
+# About
+
+[ProteoBench](https://proteobench.cubimed.rub.de/) is an open and collaborative platform for community-curated benchmarks for proteomics data analysis pipelines. Our goal is to allow a continuous, easy, and controlled comparison of proteomics data analysis workflows.
+
+ProteoBench provides a centralized web platform for developers and end-users to compare proteomics data analysis pipelines. This community-curated effort will allow for an easy and controlled comparison of tools developed or used by the participants to other state-of-the-art pipelines for specific applications. The goal is not to select a single best one-fits-all data analysis workflow, but to allow:
+
+- end-users to identify a good workflow to fulfill their specific needs
+- developers to identify the specific strengths and weaknesses in their workflows, guiding the development process
+- the field to easily position a newly published workflow within the context of the existing state-of-the-art
+
+Participants (both end-users and developers) can download a set of input files (e.g., raw MS files, search databases, or spectral libraries) tailored to specific benchmark metrics. They can then analyze the data with any workflow, and upload the results in a homogenized format. A set of metrics will be retrieved or calculated from these results and can be visualized alongside all the other metrics calculated from the results of other participants (or of curated benchmark runs).
+
+## Need more help?
+
+See [Contact](../contact.md) for all the ways to reach us.