major update of files

Author: MilagrosMarin

mkdocs.yaml

@@ -37,6 +37,7 @@ nav:
       - Open Ephys GUI: partnerships/openephysgui.md
       - Suite2p: partnerships/suite2p.md
   - About:
+      - About: about/about.md
       - History: about/history.md
       - Team: about/datajoint-team.md
       - Citation Guidelines: about/citation.md

src/elements/concepts.md

@@ -1,6 +1,6 @@
 # Concepts
 
-The following conventions describe the DataJoint Python API implementation. 
+The following conventions describe the DataJoint Python API implementation.
 
 ## DataJoint Schemas
 
@@ -22,7 +22,7 @@ reference the database schema.
     corresponding _database schema_.
 
     The module's `schema` object is then used as the decorator for classes that define
-    tables in the database. 
+    tables in the database.
 
 === "Matlab"
 
@@ -37,34 +37,32 @@ reference the database schema.
 An Element is a software package defining one or more DataJoint schemas serving a
 particular purpose. By convention, such packages are hosted in individual GitHub
 repositories. For example, Element `element_calcium_imaging` is hosted at
-[this GitHub repository](https://github.com/datajoint/element-calcium-imaging) and contains two DataJoint
-schemas: `scan` and `imaging`.
+[this GitHub repository](https://github.com/datajoint/element-calcium-imaging) and
+contains two DataJoint schemas: `scan` and `imaging`.
 
 ### YouTube Tutorials
 
-The following YouTube videos provide information on basic design principles and file organization.
+The following YouTube videos provide information on basic design principles and file
+organization.
 
 - [Why neuroscientists should use relational databases](https://www.youtube.com/watch?v=q-PMUSC5P5o)
   compared to traditional file hierarchies.
-- [Quickstart Guide](https://www.youtube.com/watch?v=5R-qnz37BKU) including 
-  terminology, and how to read DataJoint Diagrams and DataJoint Python table 
-  definitions.
+- [Quickstart Guide](https://www.youtube.com/watch?v=5R-qnz37BKU) including terminology,
+  and how to read DataJoint Diagrams and DataJoint Python table definitions.
 - [Intro to the Element and Workflow files](https://www.youtube.com/watch?v=tat9MSjkH_U)
   for an overview of the respective GitHub repositories.
-- [Overview of upstream Elements](https://www.youtube.com/watch?v=NRqpKNoHEY0) to 
-  ingest and explore Lab, Animal, and Session metadata. 
-
-???+ Note
+- [Overview of upstream Elements](https://www.youtube.com/watch?v=NRqpKNoHEY0) to ingest
+  and explore Lab, Animal, and Session metadata.
 
     Some videos feature outdated versions of the respective GitHub repositories. For the
     most updated information, check the
     [documentation page](../) for the corresponding Element.
 
 ### Deferred schemas
 
-A _deferred schema_ is one in which the name of the database schema name is not specified.
-This module does not declare schema and tables upon import.
-Instead, they are declared by calling `schema.activate('<schema_name>')` after import.
+A _deferred schema_ is one in which the name of the database schema name is not
+specified. This module does not declare schema and tables upon import. Instead, they are
+declared by calling `schema.activate('<schema_name>')` after import.
 
 By convention, all modules corresponding to deferred schema must declare the function
 `activate` which in turn calls `schema.activate`.
@@ -90,9 +88,9 @@ in a `linking_module` and passed to the module's `activate` function. By keeping
 upstream requirements in the linking module, all Elements can be activated as part of
 any larger pipeline.
 
-For instance, the 
+For instance, the
 [Scan module](https://github.com/datajoint/element-calcium-imaging/blob/main/element_calcium_imaging/scan.py)
 receives its required functions from the linking module passed into the module's
-`activate` function. See the 
-[example notebooks](https://github.com/datajoint/element-calcium-imaging/)
-for an example of how the linking module is passed into the Element's module.
+`activate` function. See the
+[example notebooks](https://github.com/datajoint/element-calcium-imaging/) for an
+example of how the linking module is passed into the Element's module.

src/elements/management/quality-assurance.md

@@ -1,54 +1,56 @@
 # Quality Assurance
 
-DataJoint and DataJoint Elements serve as a framework and starting points for numerous
-new projects, setting the standard of quality for data architecture and software
-design. To ensure higher quality, the following policies have been adopted into the
-software development lifecycle (SDLC).
+DataJoint and DataJoint Elements serve as frameworks and starting points for numerous
+new projects, setting the standard for data architecture and software design quality. To
+ensure higher quality, the following policies have been adopted into the Software
+Development Life Cycle (SDLC).
 
 ## Coding Standards
 
-When writing code, the following principles should be observed.
+When writing code, the following principles should be observed:
 
-- **Style**: Code shall be written for clear readability. Uniform and clear naming
-    conventions, module structure, and formatting requirements shall be established
-    across all components of the project. Python's 
-    [PEP8](https://www.python.org/dev/peps/pep-0008/#naming-conventions) standard offers
-    clear guidance to this regard which can similarly be applied to all languages.
-  - Python code is formatted with the [black](https://github.com/psf/black) code formatter.
-  - Line length should be a maximum of 88 characters.
+- **Style**: Code should be written for clear readability. Uniform and consistent naming
+  conventions, module structures, and formatting requirements must be established across
+  all components of the project.
 
-- **Maintenance Overhead**: Code base size should be noted to prevent large,
-    unnecessarily complex solutions from being introduced. The idea is that the larger
-    the code base, the more there is to review and maintain. Therefore, we should aim
-    to find a compromise where we can keep the code base from becoming too large
-    without adding convoluted complexity.
+  - Python's [PEP8](https://www.python.org/dev/peps/pep-0008/#naming-conventions)
+    standard offers clear guidances that can be applied to all languages.
 
-- **Performance**: Performance drawbacks should be avoided, controlled, or, at least, be
-    properly monitored and justified. For instance: memory management, garbage
-    collection, disk reads/writes, and processing overhead should be regarded to ensure
-    that an efficient solution is achieved.
+  - Python code should be formatted using the
+    [black code formatter](https://github.com/psf/black).
+  - The maximum line length should be **88 characters**.
+
+- **Maintenance Overhead**: The size of the codebase should be considered to prevent
+  unnecessarily large or complex solutions. As the codebase grows, the effort to review
+  and maintain it increases. Therefore, the goal is to find a balance that pevents the
+  codebase from becoming too large while avoiding convoluted complexity.
+
+- **Performance**: Performance issues should be avoided, controlled, or, properly
+  justified. Considerations like memory management, garbage collection, disk
+  reads/writes, and processing overhead must be addressed to ensure an efficient
+  solution.
 
 ## Automated Testing
 
 All components and their revisions must include appropriate automated software testing
 to be considered for release. The core framework must undergo thorough performance
 evaluation and comprehensive integration testing.
 
-Generally, this includes tests related to:
+Testing generally includes:
 
 - **Syntax**: Verify that the code base does not contain any syntax errors and will run
-    or compile successfully.
+  or compile successfully.
 
 - **Unit & Integration**: Verify that low-level, method-specific tests (unit tests) and
-    any tests related coordinated interface between methods (integration tests) pass
-    successfully. Typically, when bugs are patched or features are introduced, unit and
-    integration tests are added to ensure that the use-case intended to be satisfied is
-    accounted for. This helps us prevent any regression in functionality.
+  any tests related coordinated interface between methods (integration tests) pass
+  successfully. Typically, when bugs are patched or features are introduced, unit and
+  integration tests are added to ensure that the use-case intended to be satisfied is
+  accounted for. This helps us prevent any regression in functionality.
 
 - **Style**: Verify that the code base adheres to style guides for optimal readability.
 
 - **Code Coverage**: Verify that the code base has similar or better code coverage than
-    the last run.
+  the last run.
 
 ## Code Reviews
 
@@ -61,28 +63,26 @@ acceptance by DataJoint core team into the main code repository.
   GitHub fork and open a pull request targeting the `main` branch once ready for review.
 
 - **Etiquette**: An author who has requested for a code for review should not accept and
-    merge their own code to the code base. A reviewer should not commit any suggestions
-    directly to the authors proposed changes but rather should allow the author to
-    review.
+  merge their own code to the code base. A reviewer should not commit any suggestions
+  directly to the authors proposed changes but rather should allow the author to review.
 
 - **Coding Standards**: Ensure the above coding standards are respected.
 
 - **Summary**: A description should be included that summarizes and highlights the
-    notable changes that are being proposed.
+  notable changes that are being proposed.
 
 - **Issue Reference**: Any bugs or feature requests that have been filed in the issue
-    tracker that would be resolved by acceptance should be properly linked and
-    referenced.
+  tracker that would be resolved by acceptance should be properly linked and referenced.
 
 - **Satisfy Automated Tests**: All automated tests associated with the project will be
   verified to be successful prior to acceptance.
 
 - **Documentation**: Documentation should be included to reflect any new feature or
-    behavior introduced.
+  behavior introduced.
 
 - **Release Notes**: Include necessary updates to the release notes or change log to
-    capture a summary of the patched bugs and new feature introduction. Proper linking
-    should be maintained to associated tickets in issue tracker and reviews.
+  capture a summary of the patched bugs and new feature introduction. Proper linking
+  should be maintained to associated tickets in issue tracker and reviews.
 
 ## Release Process
 
@@ -108,8 +108,8 @@ upon request.
 All components will be organized in GitHub repositories with guidelines for
 contribution, feedback, and issue submission to the issue tracker. For more information
 on the general policy around issue filing, tracking, and escalation, see the
-[DataJoint Open-Source Contribute](../../../community/contribute) policy. For
-research groups that reach out to us, our team will work closely to collect feedback
-and resolve issues. Typically issues will be prioritized based on their criticality and
-impact. If new feature requirements become apparent, this may trigger the creation of a
-separate workflow or a major revision of an existing workflow.
+[DataJoint Open-Source Contribute](../../../community/contribute) policy. For research
+groups that reach out to us, our team will work closely to collect feedback and resolve
+issues. Typically issues will be prioritized based on their criticality and impact. If
+new feature requirements become apparent, this may trigger the creation of a separate
+workflow or a major revision of an existing workflow.

src/index.md

@@ -1,4 +1,4 @@
-# Welcome to the DataJoint Documentation
+# **Welcome to the DataJoint Documentation**
 
 ![pipeline](https://raw.githubusercontent.com/datajoint/datajoint-python/master/images/pipeline.png){: style="height:300px;"}
 
@@ -20,7 +20,7 @@
 
      [:octicons-arrow-right-24: Learn more](./elements/)
 
--   **DataJoint Works**
+-   **DataJoint Platform**
 
      ---
 

src/partnerships/facemap.md

@@ -88,7 +88,7 @@ and Facemap.
 - [x] Mechanism to run Facemap within DataJoint Elements - 
 [Element Facemap](https://github.com/datajoint/element-facemap/blob/0ccab4ec6731cd612e7cf61a221c64fb9bf22566/element_facemap/facial_behavior_estimation.py#L259-L266)
 
-- [ ] Tutorials on running DataJoint Element with Facemap 
+- [x] Tutorials on running DataJoint Element with Facemap - [Tutorial](https://github.com/datajoint/workflow-facemap/blob/main/notebooks/01-Facemap-DataJoint.ipynb)
 
 - [ ] Tests to verify loading Facemap data
 

src/partnerships/incf.md

@@ -1,3 +1,11 @@
-# INCF
+# International Neuroinformatics Coordinating Facility (INCF)
 
 DataJoint is a [company member of the INCF](https://www.incf.org/network/companies).
+
+In 2023, Dr. Milagros Marín and Dr. Dimitri Yatsenko presented "Research workflows for collaborative neuroscience" at INCF Neuroinformatics Assembly.
+
+From 2023 to 2025, Dr. Milagros Marín is a member of the INCF Council for Training, Science, and Infrastructure (CTSI) and the INCF Training and Education Committee (TEC).
+
+In 2024, Dr. Dimitri Yatsenko served as the Chair of the Industry Advisory Council for the INCF.
+
+In 2025, Dr. Milagros Marín joined the Scientific Collaboration and Education Theme Team (Neuro Community).

src/projects/publications.md

@@ -6,8 +6,16 @@ Title: Publications
 The following publications relied on DataJoint open-source software for data analysis.  If your work uses DataJoint or DataJoint Elements, please cite the respective
 [manuscripts and RRIDs](../about/citation.md).
 
+## 2025
+
++ Ding, Z., Fahey, P.G., Papadopoulos, S., Wang, E.Y., Celii, B., Papadopoulos, C., Chang, A., Kunin, A.B., Tran, D., Fu, J. ... & Tolias, A. S. (2025). [Functional connectomics reveals general wiring rule in mouse visual cortex](https://doi.org/10.1038/s41586-025-08840-3). *Nature*, 640(8058), 459-469.
+
 ## 2024 
 
++ Reimer, M. L., Kauer, S. D., Benson, C. A., King, J. F., Patwa, S., Feng, S., Estacion, M. A., Bangalore, L., Waxman, S. G., & Tan, A. M. (2024). [A FAIR, open-source virtual reality platform for dendritic spine analysis. Patterns](https://doi.org/10.1016/j.patter.2024.101041), 5(9). *Patterns*, 5(9).
+
++ Gillon, C. J., Baker, C., Ly, R., Balzani, E., Brunton, B. W., Schottdorf, M., Ghosh, S., & Dehghani, N. (2024). [Open Data In Neurophysiology: Advancements, Solutions & Challenges](https://doi.org/10.48550/arXiv.2407.00976). ArXiv, arXiv:2407.00976v1.
+
 + Mosberger, A.C., Sibener, L.J., Chen, T.X., Rodrigues, H.F., Hormigo, R., Ingram, J.N., Athalye, V.R., Tabachnik, T., Wolpert, D.M., Murray, J.M. and Costa, R.M., 2024. [Exploration biases forelimb reaching strategies](https://www.cell.com/cell-reports/fulltext/S2211-1247(24)00286-9). *Cell Reports*, 43(4).
 
 + Guidera, J. A., Gramling, D. P., Comrie, A. E., Joshi, A., Denovellis, E. L., Lee, K. H., ... & Frank, L. M. (2024). [Regional specialization manifests in the reliability of neural population codes](https://doi.org/10.1101/2024.01.25.576941). *bioRxiv*, 2024-01.
@@ -22,7 +30,6 @@ The following publications relied on DataJoint open-source software for data ana
 
 + Papadopouli, M., Koniotakis, E., Smyrnakis, I., Savaglio, M. A., Psilou, E., Brozi, C., ... & Smirnakis, S. M. (2024). [Brain orchestra under spontaneous conditions: Identifying communication modules from the functional architecture of area V1](https://doi.org/10.1101/2024.02.29.582364). *bioRxiv*, 2024-02.
 
-
 ## 2023 <!-- 5 -->
 
 + Celii, B., Papadopoulos, S., Ding, Z., Fahey, P. G., Wang, E., Papadopoulos, C., ... &

src/projects/teams.md

@@ -49,7 +49,7 @@ of Medicine to meet the needs of their own research. Below is a partial list of
   + <a href="https://www.fmi.ch/research-groups/groupleader.html?group=35"> Andreas Luthi Lab </a>
 + Harvard Medical School
   + <a href="https://drugowitschlab.hms.harvard.edu" target="_blank">Jan Drugowitsch Lab</a>
-  + <a href="http://datta.hms.harvard.edu/">Datta Lab</a>
+  + <a href="http://datta.hms.harvard.edu/" target="_blank">Datta Lab</a>
   + <a href="https://harveylab.hms.harvard.edu/" target="_blank">Harvey Lab</a>
   + <a href="http://sabatini.hms.harvard.edu/" target="_blank">Sabatini Lab</a>
   + <a href="https://smirnakislab.bwh.harvard.edu/" target="_blank">Stelios Smirnakis Lab</a>
@@ -126,7 +126,7 @@ of Medicine to meet the needs of their own research. Below is a partial list of
   + <a href="https://www.mackelab.org" target="_blank">Macke Lab</a> (<a href="https://github.com/mackelab/epiphyte" target="_blank">GitHub</a>)
 + University of Utah
   + <a href="http://shcheglovitov-lab.utah.edu/" target="_blank">Oleksandr Shcheglovitov Lab</a> (<a href="https://github.com/yueqiw/ephys_analysis" target="_blank">GitHub</a>)
-  + <a href="https://neuroscience.med.utah.edu/faculty/kubanek.php">Jan Kubanek Lab</a>
+  + <a href="https://neuroscience.med.utah.edu/faculty/kubanek.php" target="_blank">Jan Kubanek Lab</a>
 
 + University of Valencia
   + <a href="https://scholar.google.com/citations?user=2NKBJkEAAAAJ" target="_blank">Kai-Hendrik Cohrs</a>