Community Review: BEP038 - Atlases and Templates

[effigies]

We are pleased to announce the community review period for BIDS Extension Proposal (BEP) 038!

BEP038 extends the BIDS standard to describe BIDS Derivatives datasets that are intended to be distributed as atlases and/or templates. It introduces new organizational and metadata features, but it does not introduce new data file types.

The draft specification may be found at: https://bids-specification.readthedocs.io/en/bep038/, with the most significant changes in Derivatives - Template and Atlases and Derivatives - Imaging data types - Derivatives from atlases.

The proposed changes may be found at #1714. To view the source difference, click the Files changed tab.

Example datasets may be found at:

• atlas-4S
• atlas-AAL
• atlas-Destrieux
• atlas-DiFuMo
• atlas-HOSPA
• atlas-HarvardOxford
• atlas-Juelich
• atlas-Schaefer
• atlas-Talairach
• atlas-suit

Procedure

Review period

Community review is open from November 10 - November 21, 2025.

Voting

This discussion is a poll, which you can vote in once and cannot change your response. Therefore, please vote once you are satisfied that your answer will not change.

If you vote "No", you may create a thread to explain your reasoning or send a private email to bids.maintenance [at] gmail.com so that your position can be fully understood.

How to review

Use threads in this discussion to request clarification or changes to the BEP. Each independent topic or proposed change should have its own thread. Please review existing threads and consider adding comments to those, if your topics are already being discussed. If your concerns are adequately represented by an existing comment or comments, consider using the 👍🏻 reaction button to indicate agreement in place of extending the discussion.

Where possible, propose the specific text you would like to see added or removed.

For minor issues, such as typos, feel free to make code suggestions only, using the suggest feature on the BEP038 pull request. These suggestions may be accepted or rejected without discussion, so do not make substantial proposals in this way.

Finalization

Once the review period is finished, the BEP leads and maintainers will consider the entire discussion, identify outstanding points to be resolved, and work toward finalizing the BEP. Community members may be asked to participate in this process to provide the necessary expertise.

Before being merged, the BEP will be integrated into the BIDS validator, and the examples must pass the validator.

A BIDS 1.11.0 release is anticipated in December 2025/January 2026, regardless of the conclusion of this specific BEP.

If, for any reason, a critical issue is found after the BEP is merged, the BEP will be reverted while the issues are addressed. At the discretion of the BIDS steering group and maintainers group, depending on the scope of changes, a new community review period may be opened.

[tsalo]

I think we should remove the cohort entity completely, and canonize the <template>+<cohort> convention used in some derivatives. Even though transforms aren't covered in this BEP, they are one case where the template and cohort would need to be represented in a single entity (e.g., tpl-MNIInfant_cohort-1_from-MNIInfant+2_mode-image_xfm.txt).

I would like to avoid having to switch between tpl-<template>_cohort-<cohort>/space-<template>_cohort-<cohort> and tpl-<template>+<cohort>/space-<template>+<cohort>.

[oesteban]

@tsalo what would happen to common metadata files, e.g., _dseg.tsv file? Would you:

• allow BIDS to accept tpl-MNI to represent all cohorts (tpl-MNI+30yo, tpl-MNI+lefthanded, etc.)?
• copy the dseg TSV file over for as many MNI+whatever cohorts you have?

[effigies]

I'm not sure I follow your argument here. Are you proposing that space-<template>+<cohort> become standardized for expression a template/cohort pair? That is,

• sub-01_ses-02_space-MNIInfant_cohort-1_T2w.nii.gz -> sub-01_ses-02_space-MNIInfant+1_T2w.nii.gz
• tpl-dhcpAsym_cohort-2_space-MNIInfant_cohort-1_T2w.nii.gz -> tpl-dhcpAsym_cohort-2_space-MNIInfant+1_T2w.nii.gz

?

Assuming so, I don't really like this because it assigns a specific semantic meaning to + in this context. To now, BIDS has treated it as just another character in a label, which can be used in any way that's convenient for the curator or tool developer. To aggregate data from multiple sub-<label>_space-MNIInfant+1 files, we will now need to specify that the new space is tpl-MNIInfant_cohort-1. If the label is simply MNIInfant+1, BIDS does not have to say that the template, cohort = space.split('+'), it is just a convenience for identifying a collection of related templates. The + isn't actually the important part of @tsalo's comment: we could just as easily call them MNIInfant1 and dhcpAsym2.

As precedent here, consider MNI152NLin2009{a,b,c}{Sym,Asym}. Here we have families of related templates that each stand on their own. They could have been cohorts if the concept had existed, but using agglomerated names has been good enough, and there is no need to treat tpl and space differently.

Finally, one of the important features of a family of templates is transformations between them. The from and to labels in BEP14 have the same issues as space.

[oesteban]

Are you proposing that space-<template>+<cohort> become standardized for expression a template/cohort pair?

Not at all. Apologies if that wasn't clear.

The + isn't actually the important part of @tsalo's comment: we could just as easily call them MNIInfant1 and dhcpAsym2.

I misinterpreted Taylor's comment. I think the logic stands: we do need the meaning of cohort (for similar reasons we do need scale, in the other parallel conversation). They encode relevant parameters that are worth having disentangled from the template name.

As precedent here, consider MNI152NLin2009{a,b,c}{Sym,Asym}

Indeed, I have secretly cried because of this and I'm guilty as charged as I was there when this went through.

They could have been cohorts if the concept had existed, but using agglomerated names has been good enough, and there is no need to treat tpl and space differently.

I disagree. Sym and Asym are arguably part of the name (as they are, effectively, independent templates) but a, b and c are only about resolution. IMHO, no cohort is involved here.

They could have been cohorts if the concept had existed, but using agglomerated names has been good enough, and there is no need to treat tpl and space differently.

Like for seg-/scale-, as you indicate below: if someone wants to conflate those two concepts, so be it. People can embed sessions within subjects, or have a single subject and encode the id into the sessions. With and without + symbol, FWIW.

Meaning, if you generate a template and call it MNIInfant1, I'll cry, parse lots of duplicated metadata (that likely will be inconsistent and I will say, okay, I'll take the cohort 1 file since it's the one I'm using, but that'd be absolutely arbitrary) and do everything I could do with tpl-MNIInfant_cohort-1, with the BIDS Validator all happy about it.

As opposed to disallowing cohorts, where someone seeing the point of cohort will then have a good reason not to make their dataset BIDS compatible. I honestly don't see the value in removing cohort (nor scale).

Finally, one of the important features of a family of templates is transformations between them. The from and to labels in BEP14 have the same issues as space.

What is the issue, exactly? That you need to indicate the cohort somehow into the name? For me, that's not an issue, it is a feature and it's only needed when you need to disambiguate.

[effigies]

Could you clarify how to rewrite sub-01_ses-02_space-MNIInfant_cohort-1_T2w.nii.gz and tpl-dhcpAsym_cohort-2_space-MNIInfant_cohort-1_T2w.nii.gz?

[oesteban]

Not sure I'm correctly understanding the question, but I'll try:

• sub-01_ses-02_space-MNIInfant_cohort-1_T2w.nii.gz: This is a derivative with an atlas/template in its provenance, so, unless that has changed from the last time I reviewed this BEP, cohort should not be defined. Rewrites:

  • If this is the only file (i.e., no disambiguation needed), then cohort should not be in the name -> sub-01_ses-02_space-MNIInfant_T2w.nii.gz. The cohort, though, should be strongly recommended for inclusion in the sidecar json that applies.
  • If there more than one cohorts coexisting in the folder (e.g., cohorts 1 and 2):
    • sub-01_ses-02_space-MNIInfant+1_T2w.nii.gz & sub-01_ses-02_space-MNIInfant+2_T2w.nii.gz

• tpl-dhcpAsym_cohort-2_space-MNIInfant_cohort-1_T2w.nii.gz: evidently, we can't have the cohort entity twice in the same filename. Let's see the cases based on the space specification (and assuming the second cohort refers to the space not to the template entity):

  • Only one space specification -> drop the second cohort: tpl-dhcpAsym_cohort-2_space-MNIInfant_T2w.nii.gz
  • More than one space specification: this is an extraordinary example of the need for the three concepts. In this case, space without cohort is insufficiently specified. As before, with two cohorts 1 and 2 for space: tpl-dhcpAsym_cohort-2_space-MNIInfant+1_T2w.nii.gz & tpl-dhcpAsym_cohort-2_space-MNIInfant+2_T2w.nii.gz.

In other words, space may combine a template label and a cohort label to completely specify the space because it needs both (when cohort exists and needs disambiguation). We could explicitly show examples of this in the spec as it looks like a relatively likely case. But as for people who want to join subject and session within the subject entity, BIDS already allows it without extra changes.

[tsalo]

I don't think the scale parameter is necessary. I think atlases generated from the same data and method, but with different numbers of parcels, should be considered distinct atlases. I can see how "scale" might be useful in cases where the lower-order version's parcels are all combinations of the higher-order version's parcels, but that seems to rarely be the case. At least with the Schaefer atlas, parcels from the 200-parcel version generally seem to overlap with anywhere from 2 - 5 parcels in the 100-parcel version. I don't think it makes sense to consider that the same atlas.

[oesteban]

@melanieganz How can we not include scale and how it is not an atlas-based definition (as opposed to density, which specifies how the sampling is done on the surface)?

[oesteban]

As @effigies mentions, you could use seg- to encode the scale, but then you end up with names like seg-7Networks100regions which is encoding the two concepts. The area of regions (scale) is an important concept in neuroscience so I can't see how it should not be included.

[oesteban]

For the same reasons of the conversation regarding template/cohort, I'm going to update my example: seg-7Networks+100regions. While I prefer this over seg-7Networks100regions, I think it falls into the same problem of the template/cohort discussion. As defined by (the last time I checked) this proposal, a single segmentation (seg-) may have several scales (scale-).

[oesteban]

At least with the Schaefer atlas, parcels from the 200-parcel version generally seem to overlap with anywhere from 2 - 5 parcels in the 100-parcel version. I don't think it makes sense to consider that the same atlas.

BIDS should allow users to express the concept. It may not apply to you in the case of the Schaefer atlas, but if it does for the authors, then they should be able to share the data with their intent being as explicit as possible. That said, the fact that the parcels are not spatially hierarchical doesn't mean they can't be semantically hierarchical.

[tsalo]

I disagree that they should be considered hierarchical, even semantically, but the proposed scale entity is also a fairly straightforward new entity, so I don't think adding it will cause any major problems (beyond confusion among people who reasonably assume that such atlases would be spatially hierarchical, but that's a concern for atlas curators, not the BIDS standard).

Also just a side note: the 7-network and 17-network "versions" of the Schaefer atlas are the same atlas (i.e., parcels are the same, even if they have different labels), so I would just put those labels in different columns of the same dseg.tsv. This is what we actually do in the 4S atlas, which includes the Schaefer atlases. I'm not saying that the seg entity shouldn't be added; I just think in this case it's being used to make a distinction that doesn't need to exist.

[mguaypaq]

I'm puzzled about the "License" field in atlas-<label>_description.json (link):

• Why is it REQUIRED, when the corresponding field of dataset_description.json (link) is only RECOMMENDED?
• In fact, since a BIDS-derivative dataset is already supposed to include a dataset_description.json, why is the field duplicated? Even if a single dataset contained multiple atlases, presumably the overall dataset_description.json should describe which parts are covered by which license.

I'm also surprised that "SampleSize" is marked as REQUIRED, especially since it doesn't even appear in the accompanying example.

My proposal would be to:

• Remove the "License" field from atlas-<label>_description.json.
• Explicitly recommend using the "License" field from dataset_description.json.
• Downgrade the "SampleSize" field to RECOMMENDED.

[PeerHerholz]

Thanks for the feedback @mguaypaq, those are great points! As far as I can tell/say (others should weigh in too), @effigies is correct re the License being required for FAIR-ness reasons. Concerning SampleSize: yeah, true that. I think that's a difficult one, as @effigies said, we should ideally know that, but as outlined by @tsalo, sometimes it might not be feasible/possible. For example, when I worked on the example, some are obvious and clearly documented while others are kinda tricky. For example, DiFuMo uses various measures as input for atlas derivation and such cases might not be well covered by the current proposal/definition.

[CPernet]

License

if we have a dataset type: derivative, the atlas/template is what is delivered, then I agree than only one License is needed and having it in dataset_description.json seems more natural. If the dataset type is raw, however, then under /derivatives, the atlas-<label>_description.json should have a license for its usage. Since the second case would come from a derivative dataset, the only solution is, IMO, to REQUIRE it in atlas-<label>_description.json (less natural but more logical).

[CPernet]

+1 Downgrade the "SampleSize" field to RECOMMENDED.

[mguaypaq]

My understanding is that each folder under /derivatives is either:

• BIDS-structured, in which case it's considered to be an entire dataset (even though it is stored inside another one), and requires its own dataset_description.json,
• or not BIDS-structured at all (which is explicitly allowed), in which case BEP-038 wouldn't apply anyway.

So, I don't think a BIDS-compliant atlas-<label>_description.json would ever exist without a dataset_description.json nearby.

Also, in the case of a dataset which contains not just the atlas, it may be unclear exactly which files would be covered by the LICENSE in atlas-<label>_description.json. Presumably this would at least cover the files which have the <label> in their name, but (thanks to the inheritance principle) there may sidecar files which are needed for the atlas, but don't contain the <label> in their name.

I agree that an atlas is useless without a license, but I would hope that any given atlas is available with a suitable license from a source other than needing to be extracted from some random dataset. It just seems to me that the "natural" unit for licensing is a whole dataset.

I understand that these concerns are fairly abstract, but then again, so is the whole concept of licensing. Thanks for your work on BEP-038!

[effigies]

@mguaypaq See https://github.com/bids-standard/bids-examples/tree/bep038/atlas-4S as an example of a standalone derivative dataset where an atlas is among its sources. The idea is that it is plausible that you would not distribute the sources yourself (it may be a DataLad subdataset or just listed in SourceDatasets) but you would still reproduce the license. That helps ensure that (a) the license is respected, (b) I can check whether my dataset's use of the atlas-4S entity matches somebody else's.

For the distribution of an atlas as a dataset, yes, it is duplicative.

[mnoergaard]

I don't think it is currently clear how to create multiple templates with different spatial references. For example, given the SUIT example, the data from 20 subjects are spatially normalized to MNI, and then averaged to create tpl-SUIT_T1w.nii.gz. The corresponding json file should include the 'SpatialReference', which is 'https://templateflow.s3.amazonaws.com/tpl-MNI152NLin6Asym_res-02_T1w.nii.gz' in this case. However, if I now wanted to create the template with a new spatial reference e.g. MNI152NLin2009Asym, how should this be structured, so I don't end up with two files with the same name? Can I use the 'space' entity to distinguish these? I would suggest to allow for that.

[effigies]

Yes, that is definitely allowed for. Any filename that is permitted for a sub/ses derivative is permitted for tpl/cohort derivatives.

I'm not sure how much we would see the specific use case you describe, since it would produce multiple authoritative registration targets and parcellations that could lead to different results for downstream users, depending on which target they use. At that point, it seems less confusing to call it two different templates.

[mnoergaard]

I think it would be nice to also include a surface example using fsaverage. Given that the fsaverage spatial reference also appears https://bids-specification.readthedocs.io/en/stable/appendices/coordinate-systems.html and with the template here (https://www.templateflow.org/browse/), I would suggest to create a BIDS example using this, to also represent surfaces where the data spans multiple files (i.e. left and right hemispheres), where it is necessary to include the ‘hemi’ entity. This would probably also require to add more notation on surface-based templates and file names/extensions (such as *surf.gii?).

[effigies]

Surfaces are out of scope for this BEP. BEP011 introduces surfaces.

[CPernet]

what happened to the 3D mean SUVR PET template (bids-standard/bids-examples@e463def#diff-7abfb299aa45ecdaa05d7609e65095cc9c09f3ecec58aaeceb98dde1396bac50) ? is that the _pet vs _petmap issue related @melanieganz @mnoergaard

[melanieganz]

I am a bit confused, what are you referring to, @CPernet ? Currently the BEP038 branch of the examples has no PET example, correct? That's why we need to agree on a suffix for these type of PET derivatives here and then we can add a PET atlas example.

[CPernet]

I made the exemple already but got removed ...

[tsalo]

I think @effigies removed it because the pet vs. petmap discussion was resolved in favor of petmap, but validating the dataset wouldn't be possible until petmap (or MImap?) was added to the spec.

[melanieganz]

Yes, this is why I was trying to add MImap now, so we can include a PET example here already as well.

[mguaypaq]

To test out this BEP, I'm trying to BIDSify the PAM50 spinal cord template, and I have some questions.

The atlas folder contains several probabilistic segmentations, with one structure per file.

• I understand that I could combine all of them into a single 4D file, with one volume per structure. In that case, I would also give a JSON sidecar with a LabelMap list of strings to label each volume. Correct?
• Alternatively, I could keep each file separate, and identify each one with a label-<structure> entity, correct?
• Either way, I would need to provide an override to the Common image-derived labels. The text and several of the examples include *_dseg.tsv files for this, but I suppose I should provide a *_probseg.tsv file instead? But:
  • The template for probsegs doesn't include _probseg.tsv as a valid extension.
  • The index column is listed as REQUIRED, but it's not clear that it would be applicable for probsegs. In the case of a single volume, there is no index. And in the case of multiple volumes, this would be redundant (and/or conflicting) with the LabelMap in the JSON sidecar.
• The source atlas folder also contains a text file for the labels, which describes each individual structure, but it also describes some groupings of structures (for example, which 4 structures together constitute the dorsal column). Is there a place for such metadata in the BIDS structure?

In short: where should one describe the values of the label entity for probsegs?

[mguaypaq]

Also, in dseg.tsv, I notice that the Name column is REQUIRED, and the Abbreviation column is OPTIONAL, but maybe it should be the reverse, because Abbreviation is the string that should appear in label-<structure> entities, and Name doesn't seem to be used anywhere in particular. (Well, that would be the point of view of a parser, but I suspect that human readers would still like Name to be REQUIRED).

[tsalo]

probseg.tsv isn't supported yet (see #2246). I think you can use your own values in LabelMap. As long as the values are different from the ones in Common image-derived labels (when they refer to something different), it should still be valid, just not recommended.

[mguaypaq]

Also, I see that both label and desc are allowed entities for probsegs, and also +, and it's not clear to me what should go where. For example, among others, we have these structures in the PAM50:

WM left lateral reticulospinal tract
WM right lateral reticulospinal tract
WM left ventrolateral reticulospinal tract
WM right ventrolateral reticulospinal tract
WM left ventral reticulospinal tract
WM right ventral reticulospinal tract
WM left medial reticulospinal tract
WM right medial reticulospinal tract

• Should I use label-WM and put the rest in desc, since WM is a standard label? But each of these is not the entire white matter, only a substructure.
• Since each of these comes in a left and a right variant, should the left/right info go into desc? Unlike lateral/ventrolateral/ventral/medial, there's a clear correspondence between left/right by mirroring.
• Should I just put everything together, like label-WM+left+lateral+RST?

[mguaypaq]

In trying to BIDSify the PAM50 template, I'm also running into some missing suffixes (other than mask, dseg, probseg). In the histology folder, there are .nii.gz files which don't seem to match any of the new or existing suffixes, where the number associated to each voxel is, for example:

• The number of axons in 200µmx200µm.
• The myelin volume fraction.
• The axon volume fraction.
• The mean axon diameter.
• The mean eccentricity.

For the number of axons, it's an integer, but it's not really a dseg.
For the volume fractions, I guess you could call that a probseg, but I'm not sure.
For the last two, they're floating point numbers, but not really T1w, T2w, etc.

Is there a recommended suffix to use for this kind of data file?

[oesteban]

The problem here would be that AFAIK, there's no specification for histology images in BIDS.

Should there be a spec for histology, those maps you list feel like they could use <suffix>map suffixes (e.g., T1wmap), however I don't think <suffix>map suffixes have been accepted yet.

[mguaypaq]

I see, this part of the PAM50 is out of scope for this BEP. Thanks!

[htwangtw]

Minor error spotted in the example: atlas-DiFuMo are probability segmentations, but the example used dseg suffix.

[effigies]

cc @PeerHerholz

[tsalo]

This is out of scope for this BEP, but I am curious how other BEPs (especially BEP 017: Relationship matrix data schema and others that describe parcellated data, such as BEP011 and BEP012) will work around the atlas/seg distinction. For example, with parcellated time series, would the tsv file retain the atlas entity?

As an example, using Schaefer (since that includes atlas, seg, and scale entities):

sourcedata/
    atlas-Schaefer2018/
        dataset_description.json
        atlas-Schaefer2018_description.json
        tpl-MNI152NLin6Asym/
            anat/
                tpl-MNI152NLin6Asym_atlas-Schaefer2018_seg-17Networks_scale-400_res-2_dseg.nii.gz
                tpl-MNI152NLin6Asym_atlas-Schaefer2018_seg-17Networks_scale-400_res-2_dseg.json
                tpl-MNI152NLin6Asym_atlas-Schaefer2018_seg-17Networks_scale-400_res-2_dseg.tsv
sub-01/
    func/
        # Preprocessed BOLD data
        sub-01_task-rest_space-MNI152NLin6Asym_res-2_desc-preproc_bold.nii.gz
        sub-01_task-rest_space-MNI152NLin6Asym_res-2_desc-preproc_bold.json

        # Parcellated time series
        sub-01_task-rest_space-MNI152NLin6Asym_atlas-Schaefer2018_seg-17Networks_scale-400_meas-mean_timeseries.tsv
        sub-01_task-rest_space-MNI152NLin6Asym_atlas-Schaefer2018_seg-17Networks_scale-400_meas-mean_timeseries.json

        # Relationship matrices
        sub-01_task-rest_space-MNI152NLin6Asym_atlas-Schaefer2018_seg-17Networks_scale-400_meas-pearsoncorrelation_relmat.dense.tsv
        sub-01_task-rest_space-MNI152NLin6Asym_atlas-Schaefer2018_seg-17Networks_scale-400_meas-pearsoncorrelation_relmat.dense.json

@PeerHerholz @jdkent is this taken into account in BEP017? I just want to make sure that the proposed entities can be inherited and do not need to be modified for downstream outputs. For example, I'd like to make sure that atlas-Schaefer2018_seg-17Networks_scale-400 in the dseg file doesn't need to become seg-Schaefer2018+17Networks+400 in the parcellated time series and relmat files.

[PeerHerholz]

Hey @tsalo, thanks for bringing this up. We were/are worried about that too given things can escalate quickly as you outlined in the example. We had some meetings and during one of the maintainer meetings, @cmaumet brought up the provenance BEP, which should definitely be included in this discussion. I would definitely be 👍🏻 inheriting the entities. Also adding @jdkent, @eduff, @robertoostenveld, @arnodelorme, @sina-mansour and @CPernet for feedback here and later reference in BEP017 endeavors.

[oesteban]

@tsalo please note that space-, atlas-, seg-, and scale- are not mandatory (as opposed to task-). So, if no other clashing derivatives exist, your examples can be reduced to:

        sub-01_task-rest_meas-mean_timeseries.tsv
        sub-01_task-rest_meas-mean_timeseries.json

        # Relationship matrices
        sub-01_task-rest_meas-pearsoncorrelation_relmat.dense.tsv
        sub-01_task-rest_meas-pearsoncorrelation_relmat.dense.json

As a good principle, names should not be used to track provenance.

It is unlikely (unless some multiverse analysis with a focus on that) that you need to keep space in the name at all (neither _timeseries nor _relmat have an 3D physical space for definition). It would be a bit more likely that the derivatives contain results for more than one atlas (Schaefer 2018 and perhaps another, e.g., DiFuMo), so atlas- could become necessary. Within a given atlas, it would be more likely that you do have connectivity for several scales/segmentations (i.e., seg- and/or scale-).

It doesn't seem like a terrible problem. That said, BIDS cannot preempt someone using seg-Schaefer2018+17Networks+400.

[tsalo]

It doesn't seem like a terrible problem. That said, BIDS cannot preempt someone using seg-Schaefer2018+17Networks+400.

As long as the parcellation and connectivity BEPs support all of the entities, and doesn't, for example, require that the atlas entity in the corresponding atlas be labeled with the seg entity in a parcellated time series or relmat output, then I think it's fine. I just want to make sure that the extreme case I mentioned wasn't required by those BEPs. At one point I thought there was a discussion about atlas applying only to atlases and seg applying to derivatives made with those atlases, similar to tpl and space, and I'd like to avoid that (especially since seg is now used within atlases as well).

[cmaumet]

@PeerHerholz I think you are referring to the Provenance BEP (BEP 028). Happy to contribute to the discussions as needed!

[PeerHerholz]

Sorry, was reading "inherited" and used the wrong word, fixed now.

[effigies]

Judging by the three votes and ongoing discussions, the questions have not been resolved. Can we schedule a call for this week or next to see if we can come to a consensus? We've been doing 10-11am EST (4pm CET) on Tuesdays, if that works for people. I will also ping the email thread.

[PeerHerholz]

Should work on my end!

[tsalo]

That works for me too.

[mnoergaard]

Also works for me