Simplify license headers in source files

Currently, our source files show individual authors as well as the license in a comment near the top, for example:
# Authors: Jaakko Leppakangas<EMAIL_ADDRESS>#          Robert Luke<EMAIL_ADDRESS>#
# License: BSD-3-Clause

I think this is not ideal for the following reasons:

It is not trivial to keep the list of authors up to date. Since this information is available from Git anyway, it is also not necessary.
I don't think we have always updated these lists, so currently this information is likely outdated.
There's always the question what kind of change(s) qualifies an author to get added to that list.

I suggest that we replace our headers with the following license text across all source files:
# Authors: MNE-Python development team
# License: BSD-3-Clause

The exact wording can be changed of course (feel free to make suggestions), but the point is to get rid of individual authors.

This was also brought up by @drammock in https://github.com/mne-tools/mne-python/pull/9569#issuecomment-879969307 some time ago.
I generally agree. Do we need a copyright notice in each file? Isn't the license in the root of the repository enough, to cover it all?

Removing is even better. I don't think every file needs to have the license when there is a license in the root.

I don't think every file needs to have the license when there is a license in the root.

I was originally on board with this until I read this stackexchange thread where people sometimes (usually?) generally recommend that you do include the license so that a copied-away file still makes it clear what the license is. So I'm +0 on removing the BSD 3-clause line, I'm fine with keeping it or removing it.
Last time the "authors" stuff came up, IIRC (I can't find the thread, maybe it was in person at a dev meeting!) most people thought "yes these should go away" until @agramfort pointed out that it's a nice way for newer contributors to get some credit for what they do. I think we to get rid of the authors in mne/ but keep those lines in examples/ and tutorials/ because -- even though they, too, end up out of date -- it's nice for newer and/or less experienced people to have their name visible on something that people are more likely to read (i.e., an example or tutorial) than our whats_new.rst.

I think the changelog is a lot less visible to end-users in general than examples/tutorials

this is the point (originally made by @rob-luke as @larsoner mentioned) that convinced me to keep authors on tutorials/examples, even though I still dislike the fact that they can get stale/out of date/inaccurate.
I like the idea of removing authors from the source .py files within mne/ though. Anyone who is reading the source code I think it's fair to assume they at least know about changelogs, and many will know about git blame too. Plus GitHub shows avatars of all authors if you view the source on GitHub, so that's another way authors are visible for source files.
I'm +0.5 to keep the license lines.

my take on this and why I think it's valuable to keep names:

having your name on a file gives a sense of code ownership and
responsibility.
names on top of files survives github and where the code is stored.
I've been contacted by people to ask questions in sklearn code as they
found my name and email on the files.
for some contributors it's important to them to have their name. There
can be a sense of pride to have your name there and can maybe encourage
them to contribute more.

my 2c
Message ID: @.***>

names on top of files survives github and where the code is stored.

I find this to be the most important reason to keep names ... when files are re-organized "git blame" stops working. E.g.: https://github.com/mne-tools/mne-python/blob/main/mne/report/report.py ... I don't see my name in the git commits

even though I might be able to answer questions related to the MNE-report better than the average contributor. For functionality that is old, this may be even more critical as it might be hard to dig up who originally wrote that part of the code.

ok, I withdraw my objection to names in the source files then. It's weird that you aren't listed by GitHub as a contrib @jasmainak; you show up in the blame of that file:

I still think names in the source code only make sense if they are kept up to date. I rarely bother to put my name there, but now this makes it look as though I did not contribute. I can imagine that this is the case for others as well.
@drammock made some good points: people should not be looking at the source to find developers and ask questions. They should use our official channels. If these are not obvious, we can make them more obvisous in our documentation.
The sense of ownership and responsibility can be instilled by other means, and I think we should try to find something that works automatically. The spirit of open source is not that someone "owns" a piece of code, but we as a community have a shared responsibility for everything we create in MNE-Python. Putting some names in the sources seems to be biased and unfair unless we keep everything up to date all the time (which is not feasible).
Even if some previous contributor knows most about a specific topic I trust current developers to either answer the question or forward it to someone who they think will be able to help.
So I still think that removing names (but keeping the license) in mne/ (but keeping them in examples/ and tutorials/) is the better option.

@cbrnr i would say add your name to the files you feel a clear ownership for. I don't want your name in the files then don't.

i would say add your name to the files you feel a clear ownership for. I don't want your name in the files then don't.

It's not about me. It's that I don't like it in general for the reasons I mentioned.
So this is settled? No chance that something can be done here?

Regarding the comment by @jasmainak, you show up in the blame of the file you linked to. GitHub shows the most recent contributer per line. It's the list that's buggy, we should probably report that to GitHub.
But this file demonstrates the issue I have: @hoechenberger and @larsoner have contributed a lot, but they are not mentioned at the top of the file. Whether or not that's intentional is also beside the point, because if there is a list this indicates to others that these are the developers who contributed most and are responsible for that file. Which is simply not true.

I'm okay with having the names of the original authors of a module / function listed on top. I don't care if I'm listed even if I contributed a lot, for as long as the commit history is preserved.

But some (new) contributors might care, but not dare to ask to include their name because they might think that only original contributors or "worthy" contributions should go in this list.
That's exactly my suggestion, either we copy the full list to the header, or none. Everything in between is not fair.
Coming back to a point I thought we'd converged on (also in a previous discussion): I would leave authors in tutorials and examples, but not in sources. This was the consensus in the linked discussion in my opinion.
Re Black, it is possible to ignore revisions - is that not sufficient? GitHub should support it.

I agree with @agramfort here: it can be valuable for some, especially junior, developers to have their name in the source files. In my opinion, this should be marked by "substantial contribution".
The reason why I think this is valuable is the following: having a name on a source file is an easy way to showcase that one has substantially contributed to a specific method etc. Recruitment committees of various disciplines will probably not use a command line tool or other git/GitHub functionality to figure out contributions. However, adding a link to a file where your name is up to is easy to do.
Furthermore, people who look at the source code locally will make a connection with the names - thus increasing visibility for the contributors.
Now I agree with @cbrnr that the practice how this is done is disadvantaging contributors who are less inclined to just put themselves on the files.
I am against having all names up, as this would add a lot of text for potentially less substantial commits (e.g., having fixed a typo in the docstring etc.) and would decrease visibility.
Another possibility could be to outsource the contributor list to another file we keep on our homepage - that could fix it for my first point, but again not for the visibility.

But some (new) contributors might care, but not dare to ask to include their name

Ok right, very valid point. I've been in this situation before and I never knew when it's justified to add my name.

git --no-pager log --follow --pretty=format:"%aN <%ae>" mne/report/report.py | nl | sort -uk2 | sort -nk1 | cut -f2-

If you can add this to a commit hook that automatically runs only on the changed files and then auto updates the author list (and deduplicates with our mailmap!) then I think that would be quite a good solution. Names who only made small typo fixes will still be in there but I'd rather err in that direction than to not include names who made large contributions

I'd argue that then the name list become meaningless, no? For all points mentioned here: ownership, visibility, pride, ...

But everyone who contributed has the same right to get ownership, visibility, etc.?
Since I wanted to avoid defining what an "important" contribution is, the best solution IMO is to remove author names from source files and try to add other means to provide these perks. For everyone.

Well, my point is that with all names on there, it would not work that way.
Would someone feel ownership/responsibility if there are 15+ other names? Probably no.
Would someone get visibility if there are 15+ other names? Probably also no.
But I do think that if someone made substantial changes to a part of the code base, they should be able to get recognition for that beyond having their name in a long list of names or not mentioned at all.
At this point I also want to throw in that this might be especially important for marginalized groups in open source, which might not be just "believed" to have "really contributed".

Having observed this a bit, I want to revise my opinion. I think we should:

use CODEOWNERS for "ownership" --> this allows people to get notifications when files are touched
use our changelog for "credit"/"attribution" --> after all it's more relevant to be able to point to a specific PR that you have implemented, rather than say "I worked on this file in general"

I think what would be really awesome would be a way to filter the changelog by contributor ... something like: list me all contributions by @example-person across all MNE versions

git blame for specifics (the "black" commit can be filtered via a .git-blame-ignore-revs file, which does also work on GitHub, next to the CLI)
keep author names in tutorials and examples, AND write some loose guidelines (preferably examples) when a contribution is considered big enough to add a name there ... OR add a "author contributions" section to each tutorial/example ... something like the CREDIT taxonomy
remove names and emails from files, and only keep the license abbreviation there --> credit/ownership/blame is IMHO properly solved by the above mentioned items

@britta-wstnr

But I do think that if someone made substantial changes to a part of the code base, they should be able to get recognition for that beyond having their name in a long list of names or not mentioned at all.

While I do agree, I also see the difficulty here that @cbrnr mentioned: how do we quantify that? How big or important is "substantial"? Changed lines of code (how many?)? Performance improvements (how much faster?)? Continuous maintenance of a module (for how long?)? Do the barriers we set here depend on seniority of the contributor (beginners -> lower, senior devs -> higher barrier?)?
There must be a clear path that contributors can follow to get their name added at the top-level. Otherwise it'll be a recipe for conflict and disappointment.

@hoechenberger as mentioned in one of my earlier comments, I agree with that as well.
However, that also is a problem for tutorials and examples as @sappelhoff acknowledges and proposes to write guidelines for - i.e., we have to solve that anyway.

@britta-wstnr

But I do think that if someone made substantial changes to a part of the code base, they should be able to get recognition for that beyond having their name in a long list of names or not mentioned at all. At this point I also want to throw in that this might be especially important for marginalized groups in open source, who might not be just "believed" to have "really contributed".

I am very sympathetic to and supportive of these points.  But until we have a proposal for how "substantial" is defined and adjudicated, I feel I cannot support inclusion/exclusion of any names --- either show all names, or show none.
I think several of us agree that letting the contributor decide whether or not to include their name isn't a very good solution: it disadvantages anyone feeling shy/humble/insecure and advantages anyone feeling arrogant/confident/entitled.  But I also really don't want the mechanism to be "whoever is reviewing the PR decides" --- clearly there are differences of opinion among members of our steering council about how this should be handled, and whether a contributor gets credit in this way should not be determined by luck of the draw in who is available for PR reviews.
@sappelhoff

ideally, such a query would be associated with a specific URL that could be shared. Then I could send someone a URL and they could see all my contributions with links to the specific PRs.

This is already available: https://github.com/mne-tools/mne-python/commits?author=sappelhoff

keep author names in tutorials and examples, AND write some loose guidelines

See above point; "loose guideline" does not, IMO, eliminate the bias toward advantaging some contribs and disadvantaging others, and it adds overhead for devs to adjudicate (or at least "keep an eye out" for whether names were (not) added (in)appropriately.

Examples and tutorials are typically touched by far fewer individuals, so it should not be a problem to include all names. Even when someone "just" fixes typos (BTW I think that fixing typos is extremely valuable). So our guideline should be to include everyone who modified an example or tutorial.

There's also https://github.com/all-contributors/all-contributors if that's something you would want to implement. I'm not sure I like it that much, but it's one way to increase our focus on contributors.

To make my position clearer:
I do not think that fixing typos is "not valuable". But I think we need to find some way to give people credit who spend a lot of their time on open source work. And in a way that has little overhead for them and is easy to understand by assessment committees etc.
I fully agree that the way we do it now is not fair.
However, just erasing the names does not fix that. Adding all names does not fix that either.
--Let me be a bit more specific: if we add all names, it will again be the ones that feel less confident who will suffer. They will not feel like they can put their work in a CV (or elsewhere), because they have nothing to back it up with. After all, the names now just mean you touched a file at some point.
So in my opinion, we need to fix the fairness of the name lists (or come up with an entirely different system). Because dropping them/putting all names is not fair either.

I suppose the easiest objective measure is the number of lines a contributor touched...

My understanding of the names on the top was that it is not just for visibility, but also responsibility. Those who put their names at the top of the file take some level of responsibility for the code having substantially contributed to it and understood how it works. For instance, I would be uncomfortable putting my name in bem.py even if I may have refactored some functions ... I may not be able to help someone figure out how the equations relate to Munck's paper. Presumably, by the time someone is making such substantial contributions, they would not be shy adding their name. For small and new contributions, the changelog is always there.

@jasmainak that's what codeowners is for.

Codeowners is for the entire repo or file-level? Would you know who to ask if something is not clear in some part of a particular file?

It's file-based. You specify patterns to assign code to a person.

Would you know who to ask if something is not clear in some part of a particular file?

Honestly in cases like this I'd just open an issue and maybe tag the dev(s) who touched that code last, as reported by git blame

I feel we're digressing. I believe we didn't really mean to discuss things like, which commits belong to whom and who is responsible for which subsystem / module – all stuff that's handled for us via git and GitHub; but we wanted to find ways to acknowledge contributors. Let's try to focus on this aspect! :)

git and github provide powerful tools for tracking commits, modules etc. But at the end of the day, these tools cannot track everything. I have known of cases where someone contributed during a pair programming session and their contribution had to be acknowledged in other ways ... yes, you can use co-authored commits but in some cases, these people may not even have a github account since they are senior researchers. As Britta also pointed out above, committees may not be so git-savvy and may only look at the header of the files superficially. I think we need to strike a balance between being easy for developers vs easy for users/non-developers in understanding who is contributing and/or responsible for the code.

There was discussion of this a couple weeks ago at a dev meeting. Unfortunately nobody took notes, so I'll do my best to reconstruct the conclusions reached:

the current way things are done is both inaccurate and unfair
simply removing the names (from either source files or examples/tutorials) risks doing some harm to folks whose names are there (i.e., if they rely on their name being there as public demonstration of their contributor efforts).
until we have a proposal that does not risk such harm, no action should be taken.

cc @britta-wstnr @agramfort @larsoner who I think were the ones present for that discussion; please correct me if I'm mistaken.

I already showed a technical way to extract all authors for a file using git. So this information is there if anyone needs it. Can we make a list of persons who require this information? If there are not too many, maybe individual custom solutions are feasible (like generating a report of contributions). Are there other suggestions?

We could create that solution (a report) for them.

maybe it could be an addition to the website with a search-like tool. It would make this summary more accessible and shareable.

hosting such an interface on our website would also allow us to curate / customize what metric(s) we choose to display. Some possibities (besides number of commits):

number of PR reviews
number of issues reported
sprint or GSoC mentorship
IDK if Discourse has an API but if they do we could potentially pull in forum stats too
Getting funding to support the project

Separately, I wonder if it would help to try to separate the question of "what would be optimal going forward?" from the question of "what would preserve or improve on the imperfect situation we've inherited?" My hope in suggesting this is that we could reach some consensus about what is future-optimal, and then add to it an appropriate "patch" to try to minimize whatever harm it would do if we ignored the imperfect current/past state of affairs. Thoughts?

IDK if Discourse has an API

They do, https://docs.discourse.org/

I like the suggestion to separate the optimal solution from incremental improvements. Otherwise, we might not implement anything at all for a long time. Again, I would like to ask if anyone can give concrete examples of why and which specific statistics are important to have. This would greatly help us reduce efforts in the spirit of YAGNI.
A simple and quick (but maybe still good) improvement could be to archive all author headers in a common file, so that this information is still visible for anyone who needs it. This could be a simple text/Markdown file demonstrating contributions from particular authors (those who happened to be in the file headers) to particular files. Then we could remove authors from sources (but keep and encourage them in examples/tutorials).

A simple and quick (but maybe still good) improvement could be to archive all author headers in a common file, so that this information is still visible for anyone who needs it.

don't we have something like that here? https://github.com/mne-tools/mne-python/blob/909e45821bd004b6072a6426e4e8ea88e51b72ad/doc/changes/names.inc#L1

I understand these problems, but what I don't understand is why this is tied to having a name in the header of the source file. It's what MNE happened to choose, but I don't think that this proves contributions/competence/worth etc. when we already have other ways to demonstrate this (GitHub, git, our changelog with contributors). I think having selected names in source headers does more harm than good, so we should try to improve on the current situation rather sooner than later.

I have personally heard from folks that they used the fact that their name was in the source file to prove the extent of their contributions in the context of a job hire or promotion interaction. This is not a hypothetical. Removing their name removes their power to do that.

OK. I think they could have proved it with some other measure as well. That's exactly my point,  just because names in the source seemed to have worked doesn't mean that there are no alternatives.

I wonder if specifically for the act of job applications we could create a script that uses git to generate some stats PLUS allows for manual insertion of additional accomplishments / comments that can be added by a core team member. This information is then used to create a digitally signed certificate whose authenticity can be verified online. Just like the certificates of completion you can get via LinkedIn Learning

OK. I think they could have proved it with some other measure as well.

Why do you think that?  Why not believe them when they say "this is what worked"?

I wonder if specifically for the act of job applications we could create a script that uses git to generate some stats PLUS allows for manual insertion of additional accomplishments / comments that can be added by a core team member. This information is then used to create a digitally signed certificate whose authenticity can be verified online. Just like the certificates of completion you can get via LinkedIn Learning. We could vouch for the contributions and skills of a contributor.

I'd volunteer to draft such a document template

OK. I think they could have proved it with some other measure as well.

Why do you think that?  Why not believe them when they say "this is what worked"?

He was just suggesting that because one approach worked doesn't mean that another would not have worked. However if we want to work like scientists (evidence-based), I'd also say: what ya worked in the past has been shown to work, so why take the risk of switching to something else that might fail.

Why do you think that? Why not believe them when they say "this is what worked"?

I never said I didn't believe them. I just think that very likely other things might have worked as well. Re why not sticking to what has worked in the past, I think we have now identified the points why the current situation is less than ideal.

OK. I think they could have proved it with some other measure as well.

Why do you think that?  Why not believe them when they say "this is what worked"?

He was just suggesting that because one approach worked doesn't mean that another would not have worked. However if we want to work like scientists (evidence-based), I'd also say: what has worked in the past has been shown to work, so why take the risk of switching to something else that might fail.

The more I think about it, the more I like this idea. Imagine you could produce a document that says you've worked on MNE and it bears the signature of a certain Alexandre Gramfort (if Alex willing to play along 😅) This would provide a huge credibility boost, which, as was pointed out, might be especially beneficial to contributors from marginalized groups

I wonder if specifically for the act of job applications we could create a script that uses git to generate some stats PLUS allows for manual insertion of additional accomplishments / comments that can be added by a core team member. This information is then used to create a digitally signed certificate whose authenticity can be verified online. Just like the certificates of completion you can get via LinkedIn Learning. We could vouch for the contributions and skills of a contributor.

I'd volunteer to draft such a document template

The more I think about it, the more I like this idea. Imagine you could produce a document that says you've worked on MNE and it bears the signature of a certain Alexandre Gramfort (if Alex is willing to play along 😅) This would provide a huge credibility boost, which, as was pointed out, might be especially beneficial to contributors from marginalized groups

I think it's not easy to fix the problem of credit assignment at the level of MNE. The person evaluating a certain application will use their own metrics. If it's a person in industry, they will see github contributions favorably, but in academia, the majority still don't understand open source. If there are 20-30 authors/contributors, the evaluators have a hard time wrapping their head around your contribution percentage. I don't think it's possible to put a number on this and this is the core problem of open source cred assignment.
Job applications and grant or faculty hiring committees are one example, green card applications are another (which in turn has exponential impact on other stuff). The evaluator could be a medical doctor or an army veteran who has no idea Alex is (famous as he is :)

@jasmainak the same argument applies to having a name in a source file header. It's all pretty random/arbitrary, so I am sure that we do not have to keep names for the sake of some committee probably wanting to take a look at some source file. I completely agree with you that credit assignment for open source work is a huge problem in academia (normally this doesn't count at all).

@jasmainak

I think it's not easy to fix the problem of credit assignment at the level of MNE. The person evaluating a certain application will use their own metrics. If it's a person in industry, they will see github contributions favorably, but in academia, the majority still don't understand open source. If there are 20-30 authors/contributors, the evaluators have a hard time wrapping their head around your contribution percentage. I don't think it's possible to put a number on this and this is the core problem of open source credit assignment.

I think we're somewhat going in circles here. We have evidence that names in source files have worked for job applicants in the past. It was also argued that Git history may or may not work, depending on the job you're applying for. Lastly it was brought up that esp. for marginalized groups, even providing proof may not be enough (at least that's how I understood it) unless a respectable, trusted source vouches for these contributors. This is the specific issue I'd wanted to address with my proposal. I didn't mean to invalidate or suggest to get rid of any of the other approaches, but to introduce a new service (a certificate of contribution, if you will) for folks who believe it could help them land their next job / enter the next career stage. These certs would only be issued upon request, and the way to issue the request needs to be designed such that it is super low-threshold (filling in a simple form on our website or so).

Job applications and grant or faculty hiring committees are one example, green card applications are another (which in turn has exponential impact on other stuff). The evaluator could be a medical doctor or an army veteran who has no idea Alex is (famous as he is :)

But at least there would be some reference, which can be important for job applications.
If I've worked at a company, I can put my old boss as a reference. If I've contributed to MNE-Python once, of course I could reach out to the core team and ask if somebody would be willing to act as my reference, but there's a huge barrier there. Issuing a certificate that credibly proves I've been involved with the project, and has the name and email address of a responsible person (core dev team member) on it, creates an aura of trustworthiness and credibility.

What I'm trying to say is that it depends on the job application and the level of the candidate. In some situations, it may be enough to show "some" contributions. In other kind of job applications, you have to come across as a major contributor. If you are a Masters student applying for a PhD or to a company, I can see how such a certificate or a recommendation letter may help. But in other situations, it is pretty unhelpful if the person evaluating cannot see that you made important contributions. I'm suggesting mindfulness to the fact that there is a diversity of situations to consider.
Being able to pinpoint yourself as a major contributor to specific submodules or sister packages of MNE will probably be more helpful in more situations than having your name buried in a list of 50 or even 10 names.
@hoechenberger to avoid going in circles :)

We have evidence that names in source files have worked for job applicants in the past. It was also argued that Git history may or may not work, depending on the job you're applying for.

yes, I agree with you here

Lastly it was brought up that esp. for marginalized groups, even providing proof may not be enough (at least that's how I understood it)

I just don't know if a generic certificate would be helpful in addressing this issue. Maybe it would help in some limited circumstances ... I would ask a person who might use it.

Well, then we can make sure to put something on our website that this does not happen. My point is that names in source files are at least as flaky given that there aren't even rules who gets to be in that list.

And if this is really critical for someone, I think this person will find ways to show his/her contributions to the committee even when there are no names in source headers. It just involves a little work, but such things are very individual that I think this is best handled on a case by case basis instead of relying on our current source name bingo (sorry, but that's what it basically is right now).

I can vouch that this actually does happen. I had a certain review committees dismiss some of my contributions to some other open source work based on my name missing from a website (which it wasn't but whatever) ...

But the website isn't the source code either ... so in this case a cert like I proposed would've helped, or a page where all contributors are listed in alphabetical order, potentially with a link to that GH page that would list all commits by that user, which was suggested somewhere earlier in this thread (I cannot seem to find the posting right now), no?

a page where all contributors are listed in alphabetical order, potentially with a link to that GH page that would list all commits by that user, which was suggested somewhere earlier in this thread (I cannot seem to find the posting right now)

Perhaps you mean Mathieu's comment and/or my response to it

a page where all contributors are listed in alphabetical order, potentially with a link to that GH page that would list all commits by that user, which was suggested somewhere earlier in this thread (I cannot seem to find the posting right now)

Perhaps you mean Mathieu's comment and/or my response to it

Yea, that's it!

instead of relying on our current source name bingo (sorry, but that's what it basically is right now).

I think the discussion never was about keeping the source file names forever but more about keeping them until we have a better system in place.

One of the things I am not so sure about yet is what @jasmainak mentioned as well: if your name is on a source file that you can easily link in an application, this (for better or for worse) shows you had substantial contribution to a method. If we generate a report with all PRs, this is harder to see. Granted, there is PR names etc., but this would mean the search committee has to look through the PR list, know what a "substantial" PR name looks like or believe the candidate when the candidate says "PR x was substantial". Regarding this:

I think this person will find ways to show his/her contributions to the committee even when there are no names in source headers. It just involves a little work

This I would like to contest, as we cannot just assume that everybody has the privilege to be believed after putting in "a little work". The playing field unfortunately is not the same for everyone here.
Now, again, I don't thinkwe have to keep the header as is forever, but I think substantial contributions is one of the major "features" of source file names (biased as it might be right now) we maybe do not translate well yet.
Another one is visibility - while users can stumble across names in source files and then connect a persons name to a certain method/MNE-Python, a report on a homepage needs to be produced to be visible.
And a last thought for now: if we report those data on our webpage, we probably also need a way to be contacted about it, whether that be for wanting to be erased from the build-report-button* or whether someone thinks the reported info is not correct (e.g. because they were part of one more sprint or something like this).
*while PR lists are public information, other things might not be, e.g. sprint mentoring/attendance and the like.

Just came across this: https://github.com/mntnr/name-your-contributors
posting it as an addition to the possibilities already mentioned in this and this previous comment.

@agramfort, @drammock and I did a little bit of investigation. When you google authors (we tried @jasmainak and @britta-wstnr for example) you do not get links to source files, even if you go pretty deep in the results. You do (sometimes as the first result!) get links to examples/ and tutorials/. Based on this, the cumulative discussion and ideas above, and some additional discussion today with @britta-wstnr, @wmvanvliet, and @jasmainak (hooray sprint time making chatting much easier!) we came up with the following tentative plan.

Remove names from mne/ source files , replaced with:
# Authors: MNE-Python developers <https://mne.tools/stable/credit.html>
# License: BSD-3-Clause

Source files are not easily found by Google so don't give great credit anyway. Also sometimes people email the authors for help with code which is a bug not a feature -- people should use standard communication channels (e.g., discourse).

Create a GitHub action that:

Populates a doc/credit.rst that is roughly organized with public submodules as headings. Under each heading is a list of all authors of the file (ordered by credit, probably +/- lines over the history). This should be at least as discoverable / reportable for people who need it as having the names in the source files since it will be on our webpage, and we can link to it directly from the front page somehow.
Populates examples/ and tutorials/ Python files with all contributor names to a given example/tutorial. Since these files are already discoverable by search, we can easily keep it this way by preserving and extending/completing these automatically.

Hopefully this preserves credit "backward compatibility" sufficiently while improving things overall, especially in terms of needing to make decisions about what to include or exclude with each contribution/PR. Someone (me probably!) "just" needs to implement this stuff but really I don't think it will be too onerous having played around a bit in #11975 and with GitHub actions recently. And critically it's extensible and adjustable as needed, for example we can add sections on grant support and Discourse activity that we currently don't credit sufficiently (if at all).

Meanwhile, Scikit-Learn has had a similar discussion, and they decided to phase out individual author names in source files: https://blog.scikit-learn.org/updates/authorship-info/

Do you think we could find a solution for the upcoming release? My simplified proposal is:

Remove individual authors from source files (but not from examples and tutorials!).
As @larsoner suggested, we can include a URL in the header that links to contributors. I wouldn't bother trying to create something super fancy, let's just move contributors from the bottom of our landing page to https://mne.tools/contributors.html for now. That way, we can always add more things to that page later. I know that's not the same level of detail, but I think we have to find a balance that's not putting too much work on devs to implement, and I don't think we should wait another release.

I thought that in the light of the latest developments in Scikit-Learn, we might be able to reconsider (2). They don't implement such a highly specific credit system, and I don't know any other project that does. So I'm really proposing to follow what other projects are doing to avoid creating too much work for us devs.

in the light of the latest developments in Scikit-Learn, we might be able to reconsider (2). They don't implement such a highly specific credit system, and I don't know any other project that does.

I think any project that uses https://allcontributors.org/ or https://github.com/mntnr/name-your-contributors is probably doing a better job than either us or sklearn. So while I'm all in favor of looking to other members of our ecosystem for inspiration on ways we could improve, it's not clear to me that emulating sklearn is an improvement.
As I said in https://github.com/mne-tools/mne-python/issues/11605#issuecomment-1522436320:

I wonder if it would help to try to separate the question of "what would be optimal going forward?" from the question of "what would preserve or improve on the imperfect situation we've inherited?"

which @cbrnr agreed with (at the time at least). If we're going to do incremental steps, let's make sure they're steps forward from the (possibly marginalized/disadvantaged/unprivileged) contributors' point of view, not only from the maintenance burden for current devs view.
IMO, removing the names from the source files and also moving the contributor avatars from our homepage to some other page seems like two steps in the wrong direction (i.e. both are reducing contributor visibility).

Then just keep the contributors on the main page? I feel like we already list all contributors in the release notes, and we specifically highlight new contributors, so I think there's no need for more complexity.

Why not go all-in and write some tooling that extracts the contributors to each source file from Git and then adds all of them to the top of the file. We now have experience with CI-generated file changes with autofix.ci.
i still think there are much better ways to create contributor visibility but we've embarrassingly been unable to reach a consensus in over 9 months.

I don't like the idea of more tooling. Maybe this has been mentioned before, but why is
https://github.com/mne-tools/mne-python/graphs/contributors
not sufficient? It shows all contributors with commit-level granularity.

the current status quo is deeply unfair and inconsistent. So it doesn't really help to qualify all suggestions as steps in the wrong direction

I agree

FWIW MNE-BIDS just removed individual authors.

to explain, I have removed them (with approval) for these reasons (which have all been mentioned above):

inconsistent status quo (some authors missing on some files, not all files had an authors list, things got outdated ...)
author list in files was sort of misleading (say, one person wrote 90%, the other 10%, yet both are listed as equal)
a statement like "this is from US, all the contributors as a team" sends a nice and concise message (rather than, we work as a team, but this is only by people A, B, C), IMHO
original goal of having individual names is better covered by other means (see below)

I find it very important that FOSS contributors receive credit for their contributions, and I believe this can be accurately tracked by existing tools (which have also all been mentioned above):

git blame (and other git commands to inspect the git data)
the changelog we publish on the website
GitHub "tools" to inspect the git data, such as the contributors graph, or a author specific commit history ... or even linking to PRs
the CITATION.cff file6.
the Zenodo archive (based on data from the CITATION.cff file)
a CODEOWNERS file (we currently don't have that, but might add it in the future)
the paper in JOSS (but this is actually problematic, because not all contributors are authors on the paper)

☝ picking one of these methods is bound to give a contributor the granularity at which they want to advertise their contributions. I also believe that at least a few of these methods are suitable for non-technically versed people who want to judge the amount of a person's contributions.
For the future, I wish that we could become better (at MNE-BIDS) at tracking different kinds of contributions (contributor roles), that are potentially not picked up by the git history (e.g., informal conversations at meetings, help in the user forum, offline design work that is then committed by someone else, ...). A promising direction in that regard is the potential inclusion of "contributor roles" within the CITATION.cff standard. Note that we already add authors to the changelog if they haven't committed but contributed in another way:

Manually add authors who have done a lot of work (reviewing, advising, ...) but don't show up in the shortlog because they did not submit PRs

I furthermore think MNE-BIDS would profit from having a dedicated "contributors" page, like MNE-Python has on the bottom of the landing page.
Please note that all that I mention above is with regards to MNE-BIDS, which is a much smaller code base with much fewer contributors, so we can't copy all arguments one to one to MNE-Python.

A real-time discussion with @britta-wstnr and @larsoner today yielded the following proposal:

create a page on our website that, when called with a contributor's GH handle as a URL parameter, will dynamically create a summary of their contributions to MNE. Candidates for inclusion are:

number of merged PRs (better than number of commits because it avoids the imbalance created by switching to squash-merging around 2016 or so)
number of PR reviews
some summary of forum participation (exact metrics TBD)
leadership activity (should be API queryable from GH teams; or at least we can make it so that this is possible going forward)
participation in sprints or GSoC (easy enough to maintain a YAML or JSON of this data)
teaching of MNE workshops (again, manually-maintained JSON or YAML, but burden should hopefully be quite low)
obtaining grants or other funding
possibly other metrics, either now or later

Each metric gets a sentence or two, contextualizing what is shown (e.g., whether the sprint had competitive admission like our training sprints, or was invite-only). We can discuss whether displaying ranking for each metric is helpful/informative context or not.
The whole page gets some contextualizing info too (e.g., specifically mentions what we don't (or can't easily) track; mentions known biases in the metrics, etc).
Info is pulled via monthly cron job and dumped somewhere, and the dynamic page draws from that data source (the API queries will be too slow to do on every page load)
target is to create and merge this shortly after the next release, so that we have plenty of time to fine-tune it before it becomes part of the stable docs site.
until it's launched, we don't remove names from source files.

@larsoner and I are willing to lead the effort on building this, though @hoechenberger has indicated willingness to work on a "certificate of contribution" so hopefully this is close enough to that idea that he'd be willing to help out with this approach too.

@drammock I'm happy to work in a certificate template and also to help develop and deploy the API, I've gained some experience in both backend and frontend development including cryptography over the past couple of years
let me know if we should connect for a call to discuss and assign tasks
Great to hear we're finally moving forward here!

Sounds like a plan! I'm fine with reporting merged PRs, but just to clarify:

number of merged PRs (better than number of commits because it avoids the imbalance created by switching to squash-merging around 2016 or so)

This means that after we switched to squash-merging, every merged PR equals a single commit, right? So technically, the imbalance would not affect any new contributors, just very old contributions, right?

after we switched to squash-merging, every merged PR equals a single commit, right? So technically, the imbalance would not affect any new contributors, just very old contributions, right?

exactly right. Counting commits biases in favor of contributions prior to the squash-merge transition, and unevenly so (bias is stronger if a person commits frequently, regardless of how complex or extensive the work was)


Some links in Kotlin DSL API docs aren't rendered properly

Issue type
Styling or Accessibility
Problem description
See: https://github.com/Kotlin/dokka/issues/3703
Context (optional)
The below link to a page with problem is just an example, we have many situations, wherever we have an a href HTML link inside a @see tag in Javadoc in Java files.
Page with the problem
https://docs.gradle.org/current/kotlin-dsl/gradle/org.gradle.api.provider/-value-source/index.html?query=interface ValueSource<T, P : ValueSourceParameters?>

Updating the Dokkatoo plugin/Dokka doesn't help:

https://github.com/gradle/gradle/pull/29953


chore: run codemods for picasso icons

FX-2653
Description
I ran preset-safe codemod for icons folder
How to test

code review is enough

Review

[ ] Read CONTRIBUTING.md and Component API principles
[ ] Annotate all props in component with documentation
[ ] Create examples for component
[ ] Ensure that deployed demo has expected results and good examples
[ ] Ensure that tests pass by running yarn test
[ ] Ensure that visuals tests pass by running yarn test:visual. If not - check the documentation how to fix visual tests
[ ] Ensure the changed/created components have not caused accessibility issues. How to use accessibility plugin in storybook.

PR commands

List of available commands:

@toptal-bot run all - Run whole pipeline
@toptal-bot run build - Check build
@toptal-bot run visual - Run visual tests
@toptal-bot run deploy:documentation - Deploy documentation
@toptal-bot run package:alpha-release - Release alpha version

PR Review Guidelines

When to approve? ✅
You are OK with merging this PR and

You have no extra requests.
You have optional requests.

Add nit: to your comment. (ex. nit: I'd rename this variable from makeCircle to getCircle)

When to request changes? ❌
You are not OK with merging this PR because

Something is broken after the changes.
Acceptance criteria is not reached.
Code is dirty.

When to comment (neither ✅ nor ❌)
You want your comments to be addressed before merging this PR in cases like:

There are leftovers like unnecessary logs, comments, etc.
You have an opinionated comment regarding the code that requires a discussion.
You have questions.

How to handle the comments?

An owner of a comment is the only one who can resolve it.
An owner of a comment must resolve it when it's addressed.
A PR owner must reply with ✅ when a comment is addressed.

It looks like the codemod added a semicolon in every import. This is not an error on eslint but is conflicting with our prettier rules. Maybe we should commit without then, wdyt?
This script removed the semicolons on my computer:
git show --stat ae0340792 | awk '/^ packages/ { print $1 }' | xargs sed -i 's/;//'

ae0340792 is the commit reference hash, if you rebase it you might want to change it on the script
We would want to run prettier after every codemod, but when I tried locally it changed other places that are not related to this commit, so maybe we should run prettier in all files on a different PR in the future
Thanks for the warning. I ran prettier --write by hand and committed the result for affected files to get rid of semicolons. Looks good now 👍


Encoding error: Click doesn't like C locale on Roar

Unfortunately, iaskutils shares the same encoding error as torqueutils with the click package. I will need to update iaskutils to use argparse as well

Turns out that I actually didn't need to drop click for argparse. I only needed to add the following block of code to each of my script files:
out, err = verifylocale()
    if err != None:
        printrichtext("Uh oh. Looks like the UTF-8 locale is not supported on your system! " +
                      "Please try using [bold blue]locale-gen en_US.UTF-8[/bold blue] before continuing.")

I only needed to use the locale module to modify the locale before calling the script executable!


Observable.take(0) shouldn't subscribe to the source at all

January 17, 2018 11:37 PM:
var counter = 0
def inc() ={
  counter += 1
  1
}

val o = Observable.repeatEval( inc() ).take(0)

The fix should be that take(0) should simply return Observable.empty.
Fix should be back-ported to 2.3.x as well.

You recommendation on this page: https://monix.io/api/2.3/monix/reactive/observables/ObservableLike.html for handling groups produced by the groupBy operator which you are not interested in would not work given this change...right?


Sync homepage with history api.

The GH deployment is stable. The only issue so far seems to be pushing to history does not consider the homepage entry in package.json.

Fixed upstream. Update package.json and close


XSS error

[i] Starting scan...
[i] Checking for WAF on target URLs...
[+] No WAF detected.

[i] Payloads loaded from file.
Traceback (most recent call last):
  File "F:\lostools-main\xlsNinja.py", line 1427, in <module>
    main()
  File "F:\lostools-main\xlsNinja.py", line 1423, in main
    handle_selection(choice)
  File "F:\lostools-main\xlsNinja.py", line 1398, in handle_selection
    run_xss_scanner()
  File "F:\lostools-main\xlsNinja.py", line 869, in run_xss_scanner
    main()
  File "F:\lostools-main\xlsNinja.py", line 865, in main
    scanner.run()
AttributeError: 'MassScanner' object has no attribute 'run'

I got the same error today i've been facing a lost issue but they are not doing anything i got this error

i f anyone can help that would be great

now its fixed check upload soon the latest code

Installed the new version :D
[i] Starting scan...
[i] Checking for WAF on target URLs...
[+] No WAF detected.
2024-09-12 22:06:15,187 - ERROR - Error loading payload file: xss.txt. Exception: 'charmap' codec can't decode byte 0x98 in position 2011: character maps to <undefined>

[!] Error loading payload file. Please check the file and try again.


downgrade spring-boot

It is due to https://github.com/spring-projects/spring-data-jpa/issues/2812

@nulls by the way, do we have any plans to migrate to spring boor 3x one day ? forget, discuss we this or not

@nulls by the way, do we have any plans to migrate to spring boor 3x one day ? forget, discuss we this or not

As I remember, we have discussed it and decided to no take such big changes. But we don't have even an issue for it. Created: https://github.com/saveourtool/save-cloud/issues/1943 for tracking


Add API for retrieve, create, and update existing user(s), course(s), and session(s)

API for admin site

@developerchan1 The API is good enough, however, it has flaws on the security side which made it available publicly. Can you modify your code by adding a function or middleware to restrict access only to users with the admin role? Also, please refer to the following image on how to write a good commit message.

Hey @developerchan1 how's the progress on this pull request? Have you added a middleware to limit your api only to calls by admin?

PR merged. Thanks again @developerchan1


feat(limitTo): extend the filter to take a beginning index argument

Extend the limitTo filter to take an optional argument for beginning index. It provides a slice-alike functionality to manipulate the input.
Closes #5355

Now that there is an offset parameter, it might make sense to disallow negative limit, as it leads to weird semantics (and code).

 But it isgoing to be a breaking change :(

This PR seems good after a quick look - that is - it does what it announces. Having said this the resulting API is a bit odd... but I guess this is the best we can do without API breaking changes...
Let's reach out to the community to see what other think...

very cool thanks


git stash clear

It would be nice if an option to clear all stashes could be exposed in the command palette, as it is really slow to do it in the command palette if there is more than one.
I suggest something like this utilizing the git stash clear command

Happy to see this is something you decided to revisit. It is a small quality of life addition I most definitely will appreciate so I can use the command palette more consistently! :-)

Added with 302c41cf4e4c3de5afa8583f6da68248cea0ae86. Should be in next week's Insiders release.

Verification steps:

Open a folder/workspace that contains a git repository the does not have any stashes
Invoke the Git:  Drop All Stashes... command from the command palette

Confirm that a notification is displayed that there are not stashes in the repository

Change a set of files and create a new stash using the Git: Stash command
Repeat Step 2) couple of more times in order to have multiple stashes on the repository
Invoke the Git:  Drop All Stashes... command from the command palette

Review the warning message that is being displayed
Confirm that dismissing the dialog (Esc, or the x) will not result in the stashes being deleted

Invoke the Git:  Drop All Stashes... command from the command palette

Press the Yes button
Confirm that all stashes have been deleted


Elections crash recovery

Currently based on coclude-multiple-elections-adjustments-2.

Codecov Report

Merging #2566 into master will decrease coverage by 0.36%.
The diff coverage is 88.61%.

@@            Coverage Diff             @@
##           master    #2566      +/-   ##
==========================================
- Coverage   93.62%   93.25%   -0.37%
==========================================
  Files          45       45
  Lines        2618     2669      +51
==========================================
+ Hits         2451     2489      +38
- Misses        167      180      +13


Inquiry on Integrating Next.js for Frontend Development

Hello 👋,
First off, I must express how truly impressed I am by your innovative project that merges Electron and NestJS. The flexibility it offers to transition between a unified application and a decoupled backend for a web architecture is nothing short of amazing. As a student just stepping into the realm of frontend development, your work is incredibly inspiring to me.
I've recently embarked on a journey to learn frontend technologies and have gained a basic understanding of React. For my school project, I'm aiming to create an application that can be packaged into a binary for desktop users, while also being capable of acting as a standalone web server. The duality of your project seems to perfectly align with my goals.
Given my budding interest in React, I'm curious about integrating Next.js into the framework. Next.js appears to be an excellent choice for building optimized web applications, and I wonder if it could enhance the project by providing server-side rendering or static site generation for the frontend 🤔.
Could you shed some light on whether incorporating Next.js with your Electron and NestJS setup would be possible? Additionally, if there are any examples or resources you could point me towards, it would be immensely helpful for my academic endeavor.
I'm truly appreciative of the creativity and hard work you've invested in your project. It's an exciting opportunity for me to learn from your approach and build something unique for my coursework.
Thank you so much for your time and assistance.

Hello again 😀,
Thank you for taking the time to engage with my question and for providing such insightful feedback. I’ve had some time to reflect on your explanation regarding the architectural considerations and the role of server-side rendering within the project's context.
I now understand and agree that server-side rendering might not seamlessly fit into the envisioned architecture, particularly considering the project's current direction and the intrinsic characteristics of Next.js. On further thought and after delving a bit more into the workings of Next.js, I realize that attempting to use Next.js purely as a backend API provider might indeed introduce unnecessary complexities, or perhaps even be infeasible. This approach seems to diverge from Next.js's primary strengths and capabilities, and might not leverage the full potential of what Next.js offers for front-end development.
Given this realization, it appears that pursuing this path could detract from the essence of Next.js and potentially complicate the project without adding significant value. Therefore, I concur that closing this issue is the prudent course of action. This discussion has been incredibly educational for me, and as someone just beginning their journey into frontend development, I'm thankful for the clarity and understanding you've provided.
Your patience and willingness to explore this query have been immensely helpful, and I'm grateful for the opportunity to learn from this exchange. Thank you again for your guidance and for the impressive work on the project. ❤


Missing code signature in Kap version 3.4.1

I've received a warning that the macOS code signature in version 3.4.1 is missing (expected: Wulkano AS)- can you confirm that?
Thanks!

On it!

yea, it goes to the bin right away :(

https://github.com/wulkano/Kap/releases/tag/v3.4.2

thanks for the effort. doesn't look good however. you've used the "Apple Distribution" certificate which is only meant to be used for uploading to the Mac App Store. for distributing directly to users the "Developer ID Application" certificate needs to be used. and incidentally this one was used up to version 3.4.0...

I am sorry about this. Meanwhile, I hope this workaround is helpful: https://support.apple.com/guide/mac-help/open-a-mac-app-from-an-unidentified-developer-mh40616/mac

I just downloaded Kap v3.4.2 from the website and that's not properly signed either?

In case anyone wants to download version 3.4.0, you can do so from the releases here:
https://github.com/wulkano/Kap/releases/tag/v3.4.0

In case anyone wants to download version 3.4.0, you can do so from the releases here: https://github.com/wulkano/Kap/releases/tag/v3.4.0

Getting the same alert for this one haha. Are there problems at my end?

I am sorry about this. Meanwhile, I hope this workaround is helpful: https://support.apple.com/guide/mac-help/open-a-mac-app-from-an-unidentified-developer-mh40616/mac

I don't think this is really helpful -- the point of signed apps is not to simply allow unsigned apps to be installed.

In case anyone wants to download version 3.4.0, you can do so from the releases here: https://github.com/wulkano/Kap/releases/tag/v3.4.0

This unfortunately does not work on the latest version of macos.
@sindresorhus @skllcrn this has been an ongoing issue for more than a month. Many people are bummed out by this -- is the app no longer being actively developed?

I'm in touch with Apple support, I do not have a timeline. Getting either errors or nothing at all when attempting to generate the certificate we need... While I too understand the point signing the releases, hopefully the workaround is helpful for now.

If anyone is looking for a replacement to use in the meantime (albeit, a less feature-rich option), macOS supports screen recordings natively.
Thanks for your hard work @skllcrn 🙂

Let me know if you need help opening the app @erawhctim!

If anyone is looking for a replacement to use in the meantime (albeit, a less feature-rich option), macOS supports screen recordings natively.
Thanks for your hard work @skllcrn 🙂

I never knew this, this is amazing. The only thing is that they can have a gif from it.
It also records mic and mouse clicks. works for me directly actually

@eleijonmarck don't do it. You'll end up with screenrecording files 100s of times bigger than KAP. The Filesize is the biggest downfall.
KAP's Filesize is tiny, perfect for sharing.

This is still a problem. I can no longer use any recent version of kap on macOS 11.6.1 Intel (I haven't tried every version.) 3.4.1 and older have the code signing error, and later versions have the malicious software check error.

I had the same "issue" (Kap v3.5.1, Apple M1, macOS 12.1 Monterey) but if you just click on the small question-mark and follow the instructions you might get it to work. It worked for me. Here the instructions:
In the Finder on your Mac, locate the app you want to open.

1. Don’t use Launchpad to locate the app.

2. Control-click the app icon, then choose Open from the shortcut menu.

3. Click Open.

The app is saved as an exception to your security settings, and you can open it at any time by double-clicking it, just as you do with any registered app.

May or may not help, but I used SD Notary to help automate the code signing of an Electron-based app for Apple M1/Monterey which also kept failing until I went into the Advanced tab and ticked all the additional permissions... then all worked like magic again 🎉
SD Notary 1.4.8 Build 61: https://s3.amazonaws.com/latenightsw.com/SDNotary1.4.8-61.zip
Blog and instructions: https://latenightsw.com/sd-notary-notarizing-made-easy/


ES7 support Error: Invalid / inaccessible index name given in the URL

Can't successfully use the vsf api because of this error. I wonder this is happening because of the breaking change of ES7 (multiple type is not allowed for an index). Since default ES5.6 using "vue_storefront_catalog" as indexName and ES7 has multiple index per type "vue_storefront_{type}". I have followed all the tutorial, did I miss a thing?
This is the "vue-storefront" log
UnhandledPromiseRejectionWarning: Error: FetchError in request to ES: FetchError: request to http://localhost:8080/api/catalog/vue_storefront_catalog/attribute/_search?_source_include=activity%2Cattribute_code%2Cattribute_id%2Cdefault_frontend_label%2Cdefault_value%2Centity_type_id%2Cfrontend_input%2Cfrontend_label%2Cid%2Cis_user_defined%2Cis_visible_on_front%2Cis_visible%2Cis_comparable%2Coptions%2Ctier_prices&from=0&request=%7B%22query%22%3A%7B%22bool%22%3A%7B%22filter%22%3A%7B%22terms%22%3A%7B%22attribute_code%22%3A%5B%22color%22%2C%22erin_recommends%22%2C%22price%22%2C%22size%22%2C%22activity%22%2C%22final_price%22%2C%22id%22%2C%22image%22%2C%22name%22%2C%22new%22%2C%22original_price%22%2C%22original_price_incl_tax%22%2C%22price_incl_tax%22%2C%22product_links%22%2C%22sale%22%2C%22sku%22%2C%22special_price%22%2C%22special_price_incl_tax%22%2C%22special_from_date%22%2C%22special_to_date%22%2C%22status%22%2C%22tax_class_id%22%2C%22tier_prices%22%2C%22type_id%22%2C%22url_path%22%2C%22url_key%22%5D%7D%7D%7D%7D%7D&size=150&sort= failed, reason: connect ECONNREFUSED <IP_ADDRESS>:8080
Thank you in advance.

sorry my bad, the problem is another thing. I'll post another issue.


Unable to start multiple instances in a single VM

From a Plug.Cowboy perspective, should it be possible to run multiple instances of the Telemetry.Metrics.Prometheus in the same VM as long as they're configured to use different ports?
Our umbrella app normally runs with individual components in separate containers in production but all together in a single Erlang VM for end-to-end testing and I'm getting failed to connect: eaddrinuse error messages when more than one instance of the exporter plug web server is turned on at once. Each component runs an instance of the exporter via a module that pulls in the exporter via a using macro and runs its own instance under a different registered name. Each using macro feeds the different exporter instances a different port on startup but something is still registering a conflict.
Am I missing something about what Plug/Cowboy considers a requirement for a unique address?

@jeffgrunewald can you post the configuration you're using? There must be a conflict somewhere in your setup. If you set the port differently for each instance, it will work.
Are you getting this running under mix test by chance?

That's my hope; I figure I can always strip it down to the prometheus telemetry metrics core and macro out the webserver myself if need be but I'd rather avoid that if possible.
I get the failure when I try to start the app with iex -S mix from the platform_runner app that starts all the services in the same vm.
The relevant additions to the project are all in this draft PR: https://github.com/inhindsight/hindsight/pull/200. Of note:

The metrics_reporter library within the umbrella provides the using macro wrapper around the exporter that allows the app implementing the exporter to customize the registered process names and the port.
The service_acquire and service_broadcast applications in the umbrella both implement the metrics_reporter behaviour; acquire explicitly sets the port to 9568 and broadcast sets it to 9569.

When I start an individual app like service_acquire or service_broadcast from their own subdirectory with iex -S mix they start individually with no problem and I can verify that the getter(:port, default: 9568) directive is being applied so each app is starting the exporter on the port I'm expecting.
The getter macros at the beginning of each service is just some magic to pull the config from app_env at boot but since I'm not setting that at the moment, it's falling back to the default value in each app (9568 and 9569 respectively). That way I can set the ports to be different in each service during the all-in-one e2e test but let each one just use the default when they're running in their own isolated containers in production.

Small side note that I'm currently running off a fork of the project in my own github since the first issue I ran into was a already_started error from the web server supervisor since it's just registering itself with the module name. Was planning to open a PR if I'm able to get around the address in use error.

So it fails to finish loading on iex -S mix at the umbrella level? Or that loads successfully and then fails when you run some other code.

At the umbrella level.

But to make sure the various phoenix apps and similar components don't have conflicts you'd want to actually run MIX_ENV=integration iex -S mix from within the platform_runner sub application since that apps whole purpose is to orchestrate all the different components in this specific scenario of sharing a VM and overriding default ports via each components own integration mix environment.

So my suspicion is that macro + umbrella is not setting the values you're wanting or there is another instance of the application already running. I suggest adding some debug logs to print the port out when it runs and see where the conflict is occurring.
I can say this is not an issue with this library or cowboy. If the port is in use, that's at the system OS level. In our setup at WM, we have this working in every project. We have to set a different port when running tests in a running docker container, so the instance grabs the config at runtime and we set it differently for the test env.
I'm happy to re-open this if you can provide a failing test in this library.

Thanks for looking. From watching an lsof and dropping inspects of the config options into my fork of the library i can guarantee they are not using the same ports.
Under the hood, they are both trying to create a plug module called TelemetryMetricsPrometheus.Router.HTTP and then each one is telling that module to use a different port. I suspect that's a problem when it's all happening in the same instance of the BEAM. It's a weird and arguably artificial scenario we're in so I can understand why no one has found it to be a problem before. We probably shouldn't be doing it 😁
My takeaway is that I should be expanding my macros to create a unique router/supervisor wrapper for each service and pulling in the TelemetryMetricsPrometheus.Core library instead.

@jeffgrunewald I found the issue and it's a problem that @josevalim noted in elixir-plug/plug_cowboy/issues/20#issuecomment-571990525.
As a workaround, you can do:
TelemetryMetricsPrometheus.child_spec(name: :prom_server_1, metrics: [], port: 9987, plug_cowboy_opts: [ref: make_ref()]))
TelemetryMetricsPrometheus.child_spec(name: :prom_server_2, metrics: [], port: 9988, plug_cowboy_opts: [ref: make_ref()]))

I verified both the error you saw and this workaround locally.

Brilliant! Also verified; thanks very much!


Resubmit button

Sometimes one will want to resubmit a sample to run it again. There should be a simple button to do this almost automatically - leaving the possibility to modify some of the analysis tasks.
(So a redirect to /submit with the file part already filled out should be best).

Also a submit button for dropped files :)

I was just talking about this...  :) great idea


[$500] Android-IOU-Distance IOU amount is auto-filled and displayed in manual request money page

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Launch app
Tap fab
Tap request money
Tap distance
Tap Start and select an address
Tap Finish and select an address
Tap next
Select a workspace
Note the Request money amount
Navigate back to Request money page
Tap Manual

Expected Result:
The Distance IOU amount should not be displayed in manual request money page.
Actual Result:
The Distance IOU amount is auto-filled and displayed in manual request money page.
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android / native
[x] Android / Chrome
[ ] iOS / native
[x] iOS / Safari
[ ] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: 1.3.65-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/115492554/b59d3cb8-065b-4c2d-aa1b-19d00909db20
Expensify/Expensify Issue URL:
Issue reported by: Applause-Internal Team
Slack conversation: @
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01baf90b8cc8571594
Upwork Job ID:<PHONE_NUMBER>858043904
Last Price Increase: 2023-09-15

Proposal
Please re-state the problem that we are trying to solve in this issue.
IOU amount is autofilled and displayed in manual request page when editing Distance request.
What is the root cause of that problem?
The NewRequestAmountPage sets the default value to iou.amount which retrieves the saved amount from Onyx.
What changes do you think we should make in order to solve the problem?
Do not set the iou.amount value if the request page is not in focus.
What alternative solutions did you explore? (Optional)
None.

Proposal
Please re-state the problem that we are trying to solve in this issue.
When we go to the manual money request tab after starting a distance request, the amount from the distance request remains.
What is the root cause of that problem?
We already reset the data when the tab changes:
https://github.com/Expensify/App/blob/f67bf9f88c08fe2cebe16202d1244299a9640ea3/src/pages/iou/MoneyRequestSelectorPage.js#L64-L67
The problem is that when the manual data tab renders, the new amount value has not yet been reset in Onyx. When it is reset, we do not change the amount since there is a condition returning early if !amount:
https://github.com/Expensify/App/blob/f67bf9f88c08fe2cebe16202d1244299a9640ea3/src/pages/iou/steps/MoneyRequestAmountForm.js#L103-L105
What changes do you think we should make in order to solve the problem?

I suggest we update the aforementioned condition so that we still set the amount if it is 0:
    if (!currency || (!amount && amount !== 0)) {
        return;
    }

What alternative solutions did you explore? (Optional)
Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

Demo of my proposed solution:
https://github.com/Expensify/App/assets/138504087/9b1f465e-6792-4291-906b-0431e73e1202

Also as per this comment we want to clear the data when we switch between request types: https://github.com/Expensify/App/issues/26579#issuecomment-1703948897

We still want to reset the money request information because we are sharing the data for a draft money request. If we don't clear the data when a different tab/request type is selected, draft data from the previous type might be included in the new money request.

I've run out of time today and will test soon.

Still on my testing list

@cubuspl42 - when you get a chance, can you please review if the proposals will address this issue? Thanks!

@izarutskaya @alexpensify
I think that the "expected result" should not be just the "actual result", but negated. What amount should actually be displayed? 0?

Yeah, I think 0 makes sense.

I like the approach taken by @joh42 and @tienifr, which focuses on improving the already existing logic for resetMoneyRequestInfo, which seems to have the intention to prevent exactly what we're observing in this issue.
@joh42 was first here, but I think that the hook-based solution by @tienifr is the better one.
So I say we go with @tienifr here.
C+ reviewed 🎀 👀 🎀

@marcochavezf - we need a review here, please. Thanks!

I've bumped @marcochavezf in Chat.

Thanks for the review @cubuspl42, also @tienifr's proposal looks good to me 🚀

This is being taken care of

@cubuspl42 - to prepare for the payment date, can you please complete the checklist? Thanks!

The PR that introduced the bug has been identified. Link to the PR:

https://github.com/Expensify/App/pull/25707/files#r1348624232

The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:

[N/A](https://github.com/Expensify/App/pull/25707

A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:

No need for additional discussion

Determine if we should create a regression test for this bug.

Up to the QA team

If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.

Launch the app.
Tap the Floating Action Button (FAB).
Select the 'Request Money' option.
Access the 'Distance' feature.
Click on 'Start' and choose a specific address.
Click on 'Finish' and designate a different address.
Proceed by tapping 'Next'.
Choose your preferred workspace.
Take note of the 'Request Money' amount displayed.
Navigate back to the 'Request Money' page.
Select the 'Manual' option.
Confirm that no amount is set (you should see a slightly greyed-out 0)

The PR that introduced the bug has been identified. Link to the PR:

https://github.com/Expensify/App/pull/25707/files#r1348624232

The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:

https://github.com/Expensify/App/pull/25707

A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:

No need for additional discussion

Determine if we should create a regression test for this bug.

Up to the QA team

If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.

Launch the app.
Tap the Floating Action Button (FAB).
Select the 'Request Money' option.
Access the 'Distance' feature.
Click on 'Start' and choose a specific address.
Click on 'Finish' and designate a different address.
Proceed by tapping 'Next'.
Choose your preferred workspace.
Take note of the 'Request Money' amount displayed.
Navigate back to the 'Request Money' page.
Select the 'Manual' option.
Confirm that no amount is set (you should see a slightly greyed-out 0)

My mistake, I missed that there was a regression here but was addressed quickly. I need another day to review and confirm the payment amounts. For now, I've paid the reporter.

Here is the payment summary:

External issue reporter @ashimsharma10 $50
Contributor that fixed the issue @cubuspl42 $500
Contributor+ that helped on the issue and/or PR @tienifr $500

Upwork Job: https://www.upwork.com/jobs/~01baf90b8cc8571594
*If applicable, the bonuses will be applied on the final payment
Extra Notes regarding payment: This GH would fall under an urgency bonus but due to regression there won't be one. We did fix the issue quickly, so I'll be keeping the base pay as is for the contributors.

Everyone has been paid in Upwork. I need to create the regression test and will close it.

Not overdue, I need to create the regression test.

Contributor that fixed the issue @cubuspl42 $500

Contributor+ that helped on the issue and/or PR @tienifr $500

It's the opposite, but doesn't matter much I guess

Alright, I updated the summary based on the @cubuspl42 feedback Also, I created the regression test, so I'm going to close this out.


How can we disabled audio/video track while connecting and enable the same track later?

How can we disabled audio/video track while connecting?

Step to reproduce:

Connect to room
Disable video track immediately after connect
In web twilio js, track for video event is coming but disabled, still track is active for an opponent.

Do we have anything similar to web in native SDK which can disable track while connecting?
Video.connect(videoAccessToken, {
        name: videoRoomId,
        audio: false,
        video: false,
        ...
      })
}

How can I disabled video track at the creation time, then later create video track and set with builder if user wants to enable?
builder.videoTracks = disableVideo ? @[ ] ; @[ self.localVideoTrack ] ;
// Now how should we assign the video tracks later while in call ?

@Balasnest,
A LocalVideoTrack can be published either when you connect to the room via the videoTrack property of the ConnectOptionsBuilder or can be published at a later time via the LocalParticipant.publishVideoTrack(_ track: LocalVideoTrack, publicationOptions options: LocalTrackPublicationOptions) method.
Ryan

@paynerc Yeah. I have managed to get it to work. Thanks!


Last Opp Amount set incorrectly when two donations occur on the same day

If two donations are made on the same day the Last Gift Amount field "npo02__LastOppAmount__c" on Accounts, Contacts and Household object does not get populated with the last amount donated, it reflects the first amount that was made on that day. Is this a known bug? #NPSP
SEE NOTES IN GITHUB.

closing this.  if you have two donations on the same day, i congratulate you :)


#add handlers for fly update layers

Hello, this is update for resolve fly updates layerTypes by new props (now they can inititialize with map 1 time)

@istarkov, remove sort/isEqual logic, left only ref equal

Thank you!

0.21.3


Wrong formula

https://github.com/izhengfan/se2lam/blob/ec054e5b749654776060bf6bbb7e0c65ea04b90e/src/ORBmatcher.cpp#L157
It should be:
const float factor = HISTO_LENGTH / 360.f;

Since "HISTO_LENGTH = 30", the difference angle of two KeyPoints will distributed in 30 regions with 12 degrees per region.
This code here will result in 30 degrees per region.

I think you are right. This cpp file is copied from the ORB_SLAM repo, so I guess this bug originates from it.


Access the menu to change resolution

Hi, I saw an youtube video where the person could access a menu to change various configurations, including setting a custom resolution, how could I access this menu?

It's a different tool: https://mbucchia.github.io/OpenXR-Toolkit/
But I don't recommend that you change the resolution there, just use the Virtual Desktop quality settings to control resolution.


[AntaresWeb] Output disappeared

Description
I launched simulations on 3 studies which are variants of the same initial study. All three simulations went well and the results were initially accessible.
When trying to access them several hours later, the results had disappeared: they can't be seen in the "Results" tab or in the debug view. However, they are still downloadable from the "Tasks" view.
The outputs of 2 studies were accessible again several hours later, but they are still invisible for one of the studies.
The size of this study is identical to the size of a study with outputs, suggesting that the outputs are there.
Steps to Reproduce
Initial study ID: 390e2a89-2abe-4707-bf59-bd1877d8429e
Variant study ID which output has disappeared: 7aa4f373-5e3e-40ff-be02-88c76c160eca
Antares version of the study: V8.0

I reproduced the bug and created a test that used to fail and now succeeds.


Gradio: "Something went wrong: connection errored out" when using Harvest for conversion

You see, when I want to generate an audio using Harvest, (inference stage), the Gradio interface keeps processing until it ends in the mentioned error. However, the audio is generated successfully because it appears in the TEMP folder after a few minutes, so that's where I have to download it from.
Is there any way to solve the gradio error with Harvest conversions? Thanks!

I guess it's because the generating time was beyond RVC's timeout. @RVC-Boss

I guess it's because the generating time was beyond RVC's timeout. @RVC-Boss

how to solve the problem? thanks

Same problem. I tried everything I could. Although there was no such error before. @RVC-Boss

FYI, the "Connection errored out" message is only for the Gradio Web UI but processing still happens in background.
If you let enough time for it to happen, the output file will be added to the TEMP directory.

I seem to experience the same thing, any ideas how to fix it? Like how to let enough time to let processing finish?

I have the same error message using RVC WebUI. I am able to train my model, but in the Model Inference, when I try to convert, after 20 seconds I get the message:
Something went wrong
Connection errored out.
Command prompt closes automatically. TEMP folder is empty, The conversion is not complete,

I have the same error message using RVC WebUI. I am able to train my model, but in the Model Inference, when I try to convert, after 20 seconds I get the message:
Something went wrong Connection errored out.
Command prompt closes automatically. TEMP folder is empty, The conversion is not complete,

I am getting the same problem. No errors on console, it just closes and process ends

I have the same error message using RVC WebUI. I am able to train my model, but in the Model Inference, when I try to convert, after 20 seconds I get the message:
Something went wrong Connection errored out.
Command prompt closes automatically. TEMP folder is empty, The co

I have the same error message using RVC WebUI. I am able to train my model, but in the Model Inference, when I try to convert, after 20 seconds I get the message:
Something went wrong Connection errored out.
Command prompt closes automatically. TEMP folder is empty, The conversion is not complete,

This is exactly what i am experiencing after updating and fresh install... i've been using and converting with rvc for a few years now and this has NEVER happened.... i hope something gets fixed cause when i click convert after 30 seconds right before it would normally finish and spit out file, it cancels and connection errored out and nothing happens and conversion stops.... Never had this issue happen before

I have the same error message using RVC WebUI. I am able to train my model, but in the Model Inference, when I try to convert, after 20 seconds I get the message:
Something went wrong Connection errored out.
Command prompt closes automatically. TEMP folder is empty, The conversion is not complete,

I have the same error message using RVC WebUI. I am able to train my model, but in the Model Inference, when I try to convert, after 20 seconds I get the message:
Something went wrong Connection errored out.
Command prompt closes automatically. TEMP folder is empty, The conversion is not complete,

This is happening to me as well... after using rvc and converting for 3 years now, i've never had this issue.... i've recently deleted and reinstalled rvc for a fresh new install in case it got better.... but i amd now unable to convert anything either..... 30 seconds after clicking convert when normally it would finish, it just stops, cancels and connection times out and nothing more can happen.... no idea why this is happening but it seems others are having it too... maybe it's an update they did, i hope so, cause if it's something major on my end, i wouldn't have a clue how to start to fix this kind of issue... i'd never solve it


[FR] Change to a more standard file format to store snippets

Very happy that #39 be implemented! Now I can use ultisnips in vim to quickly creat snippets :smile:.
However, current snippet file use a strange format (array in js?) , thus for syntax highlighting and checking to work, we have to write relevent configs from scrach, which is a REALLY pain...
I think it's better to switch to some more standard formats to solve that. Switch to json may only require minimal effort, though it appears to not support comments?
I'm personally in favor of toml for it's readability and native support of comments. We may specify a snippet like this:
# some comment
[[snip]]
trigger = "mk"
replace = "$$0$"
options = "mA"

Hello!
The snippets are perfectly valid JavaScript, so saving your snippet file as a .js file should give you syntax highlighting. (However, snippets are actually parsed by the plugin using json5. It's an extension of json which adds support for comments among other nice features.)
In the future, I can consider changing the format if there is significant demand.

Is there a way to edit the .js file in Obsidian with syntax highlighting? I know can I view the files in the file explorer by changing Files & Links > Detect all file extensions to true, but then I cannot edit them in obsidian, it opens them in my external editor configured for that filetype.

Well, I found a temporary fix for the problem: Just put it in a markdown file and wrap the code block in javascript block comments like this:
Note I use ' instead of ` here because github really does not like nested codeblocks
/*
'''js
/*

<your snippts>

/*
'''
*/

Pros:

it works

Cons:

ugly /* and */ in my snippets
really more of a hack than a solution


Correct rotation degree mapping

Corrected rotation degree mapping to Orientation Exif tag in ExifUtils.kt

Can you please clarify what specific scenario this fixes? How can we test that this works?

Closing from lack of action


Feature/ie11 support

existing header is not support IE 11, but it's still in jobsdb support browser list.
BREAKING CHANGE:
Add package polyfill and change some css for cross browser support.

https://trello.com/c/ySgJXjgM/128-bug-login-sign-up-module-is-not-displayed-in-global-header-under-ie11

http://seek-asia-style-guide--7f053ef537574b19dfe3cac0150ba60863c48234.surge.sh/jobsdb-header/

Do we have scope to fix this while we're looking at header spacing?

@mengtzu no, we have no plan for the spacing problem, this PR is just to solve the ie11 problem for homepage scale up😀

OK, fair enough, I'll chase that up elsewhere 😅


alter .npmignore for npm package

cc/ @ryan-roemer
This PR adds .babelrc and .eslintrc to .npmignore only for the published npm package. These configs both reference node_modules/builder-victory-component... which will not be found in the npm installed package. This should only be problematic in weird edge cases (i.e. not excluding node_modules when transpiling or linting) but we've already hit it twice in the last two days, so better safe than sorry.

related to https://github.com/FormidableLabs/victory-docs/pull/175 and https://github.com/FormidableLabs/victory/issues/416


extend/os/mac/keg_relocate: remove RPATHs rooted in build directory

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew typecheck with your changes locally?
[x] Have you successfully run brew tests with your changes locally?

Keeping dangling RPATHs is a security risk, and is bad for build
reproducibility.

I'm tempted to remove all RPATHs referencing non-existent directories, but I don't know if that will break anything.
Note that delegating delete_rpath doesn't work here. See https://github.com/Homebrew/ruby-macho/issues/355.

Review period will end on 2021-05-14 at 23:46:37 UTC.

Re deleting RPATHs that reference non-existent directories: I'd revisit it when we're happy with the current relocation code. I don't want to change too many things at once here.

Review period ended.


Fix #4 and Fix a problem with picture/thumb

I have added an helper (UrlNormalizer) to add the http protocol if it is not present (lbc seems to have removed it).
Tests are ok but content test is not very up to date.

Problem solved in 1.0.6


add a release tag

it'd be nice if a release tag could be added so I can depend on that instead of depending on ~master, which could break without notice.

I've added a tag (even if it's only 0.0.1-alpha.1) and moved cairoD to https://github.com/cairoD/cairoD


Composer on docker cannot find runtimes folder, therefore, cannot start bot

Describe the bug
When running from docker, clicking to start bot runs really quick... But emulator cannot reach the API.
Running _ ps aux_ from inside the container, it shows no dotnet process running.
Checking the /hostedBots/XXX/runtime folder, it's empty.
Checking the localPublish/src/index.ts file, it copies the runtimes from ../../../../runtime folder,which falls to /app/Composer/runtime, and not /runime.
Version
1.0.2
Browser

[ ] Electron distribution
[ ] Chrome
[ ] Safari
[ ] Firefox
[ X ] Edge

OS

[ ] macOS
[ X ] Windows
[ ] Ubuntu

To Reproduce
Steps to reproduce the behavior:

docker-compose build
docker-compose up
Open //<IP_ADDRESS>:3000
Create a new EchoBot - doesn't matter the path
Start Bot and Run on emulator (ngrok required)

Expected behavior

Bot to start up
Bot emulator to successfully send the first conversationUpdate message (HTTP Status 200)

@cdonke thank you for submitting changes to address this! tangentially--can you share more information about your scenarios and use of dockers and containers with Composer?


Add: IntersectionObserver's options support

This PR allow to load image just before the element is visible in the viewport by setting a margin where the loading is triggered
This margin can be customized with the load-magin-* attribute
It's needed to set the scroll-element attribute with the element who have the scrollbar if this is not the default scroll behavior (by setting overflow CSS propery) ; else the margin will not be taken in account

ping ?


Archive fails when trying to archive to an existing file

Description
If I try to archive to a separate file I get an error message if the file already exists.
Settings

Version: 0.26.1
Archive to a separate file: Checked
What kind of file to use?: Custom Note
File Name: Misc\Archive\Completed Tasks

Expected Behavior
First Archive

File will be created.
Tasks is moved to new file

Subsequent Archives

Tasks will be added to the already existing file.

Actual Behavior
First Archive

The file is created and a message saying "1 Task Archived".
Task is shown on the Misc\Archive\Completed Tasks page.

Subsequent Archives

Task is deleted from original page.
Error message saying "Error: File Already Exists" is displayed.
Task does not appear on the Misc\Archive\Completed Tasks page

I also have this problem.


Unit test a rule that is disabled by default?

I have been looking at ways to use ktlint-test and my own mechanism for spinning up a KtlintRuleEngine, but there does not appear to be a simple way to unit test a custom rule that is disabled in the default .editorconfig.
Expected Behavior
I'd like to be able to create a custom rule, disable it by default, then unit test that it works (when it is not disabled). For example, let's say I have a custom rule that prevents me from importing "com.github.foo", and I have it configured for ktlint:my-rules:import-foo. I set this as disabled in my default editorconfig:
ktlint_my-rules_import-foo = disabled
Then I write a unit test against it. It might be something like this:
@Test
fun testFoo() {
    val latch = CountDownLatch(1)
    var result: LintError? = null
    KtLintRuleEngine(setOf(RuleProvider { FooImportRule() })).lint(Code.fromSnippet("import com.github.foo")) {
        result = it
        latch.countDown()
    }
    latch.await(1, TimeUnit.SECONDS)
    assertNotNull(result) // Fails here
}

The expectation is that the test should pass
Actual behavior
The only way it passes is if I remove the line I configured in .editorconfig, such that the rule is not disabled.
Additional information

Current version of ktlint: 0.50.0

When using the ktlint-test module, you can write your unit tests using the ktlintAssertThat functionality. This is used by almost all unit tests in ktlint.
The missing piece, might be how to disable a rule. For most properties this is simple, but for disabling a rule it is a bit more complex. It can be done as follows:
internal class SomeRuleTest {
    private val someRuleAssertThat = assertThatRule { SomeRule() }

    @Test
    fun `Some test`() {
        val code =
            """
            // some code with violations that are detected by SomeRule if it is executed
            """.trimIndent()
        someRuleAssertThat(code)
            .withEditorConfigOverride(SomeRule().ruleId.createRuleExecutionEditorConfigProperty() to RuleExecution.enabled)
            .hasViolations(
                // check your violations
            ).isFormattedAs(
               // formatted code
           )
    }
}

But in my opionion this should not be tested for each rule that you implement. It is logic that is tested by ktlint with some rule. See https://github.com/pinterest/ktlint/blob/a679dd4f2e84288e98d6d06a42091bcf0b0087a8/ktlint-rule-engine/src/test/kotlin/com/pinterest/ktlint/rule/engine/internal/rulefilter/RuleExecutionRuleFilterTest.kt#L4


Fixed SyncPromiseAdapter::all() to not change the order of arrays

Right now, SyncPromiseAdapter::all() changes the order of arrays when resolving promises. For example, an array that should be
Array &0 (
    0 => '1'
    1 => 'value1'
    2 => 'value2'
    3 => 3
    4 => 'value2-value3'
    5 => Array &1 ()
)

is instead
Array &0 (
    0 => '1'
    3 => 3
    5 => Array &1 ()
    1 => 'value1'
    2 => 'value2'
    4 => 'value2-value3'
)

As a consequence, the array will be converted to a JSON object with numeric keys when encoding as JSON. json_encode() only converts arrays with incremental integer indices to JSON arrays.
This problem is actually detected simply by changing assertEquals() to assertSame() in the tests. I recommend to generally use assertSame() much more often than is done in this project (169 uses of assertSame() vs. 562 use of assertEquals()) to more easily discover similar flaws.

Thank you for the great work on this library by the way, I really love it! :ok_hand:

Coverage increased (+0.001%) to 93.596% when pulling e35b57601df3194cb4e1c79498b93a2239fa74f8 on webmozart:sync-promise-adapter-indices into ed41a4ce43e354a0e2218d11c78b5d1ab86e3140 on webonyx:master.

Thanks for the fix!
I do agree that assertSame is usually more appropriate, but my IDE shows diff of expected / actual result when assertEquals fails and shows nothing useful  for assertSame (apart from error message). Streamlines writing tests a lot.


New process flow for OST Remote time import

This is a full rework of the post-import processing flow for raw times coming in through the Api::V1::EventGroupsController#import endpoint.
Begins to address #311
Should also address https://github.com/SplitTime/OpenSplitTime/issues/274 and https://github.com/SplitTime/OpenSplitTime/issues/265

This PR has gotten quite stale, and it is likely not worth attempting to resolve conflicts with master.
Closing in favor of some future effort to simplify and modernize the raw time import process.