Do we really need a Code of Conduct?

This issue is the result of a discussion I held on Reddit (nolink) and the following is a piece of my exchange with one of the users who shall remain anonymous:
The context is the following article:

http://dancerscode.com/blog/why-the-open-code-of-conduct-isnt-for-me/

Later, somewhere in the middle of the argument (whether a CoC is even healthy for the project or not) I asked:

@bucaran: Are you saying that I should consider {modify,adapt}ing the CoC to prevent future trouble? Thank you for pointing this out. I'll read the article now that I see what you mean. Do you have any tips?

@reddit-user: First, my opinion. And explicitly opinion. I do not think that code of conducts should exist. Anything not in the software license is irrelevant, long-term. As such, I would include something like the NoCoC to make the point explicit.

Secondly, tip. My opinion notwithstanding. Whatever you choose, look at it long and hard. If it could be argued that it would disallow things you wish to keep, it has problems. Ditto, if it includes anything that someone could not realize would fall under its domain, it has problems. Ditto, if it includes anything that is the case because someone says it is the case. (For instance, I could consider you insisting the sky is blue was harassment, which would make you in violation of your project's CoC.) Ditto, if it includes anything where it requires "common sense" to determine the scope and/or consequences, it has problems. (This is very much in line with the problems with discrimination against blacks in the US - laws were there but they were not enforced against black victims, or when they were they were with the minimum possible penalties.) In particular, look at anything subjective.

Your current CoC is such that you'll drive people away, in the sense of "why should I sink time into writing a good bug report / pull request / etc. considering they say that my work is not judged on its merit?".

I want to include everyone, of course, and I love teaching others too, but I would always judge your work and opinion based on its merit / value and not on anything else.
I would like to ask other folks what they think and whether we should simply remove Fisherman's CoC or keep it.

I think the person gets two things thoroughly confused. A Code of Conduct is a social contract, ensuring that every person deciding to participate in a project knows that they can do so in a safe way. That is entirely distinct from judging a work the user presents you, in the form of code, documentation or anything else, by its merit.
Codes of Conduct exists to ensure that if someone is attacked, marginalised or otherwise discriminated against, which cannot occur purely based on their work (because that would mean that their work somehow equates to their gender(identify), ethnicity and what else), have the ability to raise such an issue to project maintainers. It is at the maintainer's discretion to decide what to do with this and what community they want around their FOSS project. It is meant as a way to settle a dispute, not a card you can pull just because you find someone annoying. If that's how a project maintainer allows its Code of Conduct to be abused, that's on them.

CoC it is a good idea, I also think that if your first input was to add one, it is also a good reason to keep it.

I'd suggest updating to Contributor Covenant 1.4, as it contains more positive language instead of just what happens if you do something bad.

Link: http://contributor-covenant.org/version/1/4/

@jrobeson What about https://github.com/domgetter/NCoC?

Personally I use the Open Code of Conduct in my projects, e.g.:
https://github.com/jab/bidict/blob/master/README.rst#participation

I support the CoC and especially agree with everything @daenney said.  I really dislike the "ugh political correctness" argument as it just smacks of laziness.  I believe that part of being meritorious is being respectful with how you phrase things in your code, comments, PRs, issues, etc.

The problem I see with the NCoC is that it doesn't handle the case very well of what happens we it does turn unfriendly. It doesn't really state anything about expected behaviour either except that "we can all have adult discussions". I think we've seen more that enough proof by now that that is not necessarily the case.
I also find language like this in the NCoC unfortunate, to the point of being dismissive of what we're actually trying to solve:

If it's truly a problem and you're truly an asset to the community then you will probably get an email back.

It shouldn't, ever, matter how important of an "asset" you are to the community. Wether it's someone who's been with the community for years or someone who just submitted his first PR to your FOSS project. Even more so, if someone's first contact with a FOSS project happens badly and because we don't deem them important they don't get an adequate response, what example are we setting?

NCoC solves no problems.  I think it's been pretty well proven that the assumption of

We are all adults. Capable of having adult discussions.

has been proven false.

@daenney

If people find that having a Code of Conduct, which basically equates to saying "we expect everyone who participates to be excellent towards each other" unreasonable, that's fine.

I don't think anyone who is against a CoC in general is against "we expect everyone who participates to be excellent towards each other" to be the code of conduct.  It seems you've constructed a straw man.

I also find language like this in the NCoC unfortunate, to the point of being dismissive of what we're actually trying to solve:

If it's truly a problem and you're truly an asset to the community then you will probably get an email back.

That's not part of the NCoC, it's only an example of how such a community may handle conflicts.  The NCoC is simply

This project adheres to No Code of Conduct. We are all adults. We accept anyone's contributions. Nothing else matters.

I'm not a part of the fisherman community, so I don't claim to speak for anyone here, but please don't misrepresent the NCoC.

@domgetter I didn't mean to misrepresent anything. It's how I interpreted the wording of the NCoC and the examples given.

@domgetter : I know I represented it correctly (by quoting from it), and that is exactly what I find unacceptable.

What would be a situation in which relying on the CoC could actually turn against us? I haven experience with this, but after reading bits from this discussion you got me thinking. Also, the other day, I had a surreal exchange for almost half an hour with a Korean friend of friend in which I was questioned for choosing "Fisherman" as the title of the project, instead of "Fisherwoman".

What would be a situation in which relying on the CoC could actually turn against us?  I haven experience with this, but after reading bits from this discussion you got me thinking

Could you be more explicit?
I've seen people try to abuse a CoC but that only ever works if the maintainer(s) let them. With a CoC, the maintainers are the ones making the final call and decide on how to apply the CoC and if it is an appropriate situation for the CoC to be called upon.
For example; if someone raises an issue because someone used insulting language towards them, that's fair. However, if that person than uses the CoC to justify a crusade against that person, or "return the favour", that's unacceptable behaviour /  harassment in my eyes and a violation of the CoC (depending on your CoC, I'm referring to the Contributor Covenant in the back of my mind).
In most CoC's there's a section along these lines which, in my eyes, gives the maintainers enough wiggle room to stop any such behavior (this again lifted from the Contributor Covenant):

Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.

If there's any doubt I would suggest bringing in a trusted number of members to the discussion and come to a resolution as a community.

NCoC is garbage. Opting to put the NCoC on your project instead of just not having a CoC at all is basically a big "fuck you" to anyone who wants a CoC or to anyone who cares about this kind of thing.
Also, the original linked article is incredibly misguided, and that quoted reddit user is equally misguided. A Code of Conduct is not a tool that can be used to harass other people, it's the complete opposite. A Code of Conduct cannot be used to label arbitrary opposing opinions as harassment, since a Code of Conduct isn't a set of absolute rules enforced by a robot and triggered by someone claiming offense, but is in fact a set of guidelines that are enforced by human moderators (e.g. project authors or community moderators) and are therefore subject to human interpretation. Which is to say, if someone is making an obviously bogus claim of harassment (such as that redditor's ridiculous claim about how insisting the sky is blue can be harassment), that simply isn't going to fly as no human moderator would go along with it.
And that redditor's final paragraph about how a CoC will drive people away is also completely nonsensical. The only people that would be driven away by a CoC are people who recognize that they will likely violate it, and are therefore the people that the CoC is intended to protect the community from (which is to say, the CoC is doing its job). And you'll find plenty more people who will be interested in participating in a large part because the CoC exists and makes them feel like it's safe to participate.
As for updating to the Contributor Covenant 1.4.0, it looks like the only notable difference is the addition of positive examples, which seems reasonable though I have no strong opinions about that vs the current CoC.

@daenney It's all good.

However, I do find it unfortunate that you chose to jump to "misrepresent" instead of assuming good faith on my part. It's human to misunderstand or misinterpret things...

I never claimed you did it intentionally.  Perhaps I used the wrong word.
@jrobeson

Because I can't trust people to act like adults.

The entire discussion is a matter of degree, not kind.  If there was only ever one identifiable instance of sexism being bad for Open Source Software, surely it would be shortsighted to impose a set of rules that no one was breaking in the first place.
I don't think this is the place to get into a discussion about whether or not there's enough sexism for us to do something about, and whether or not, even if that's true, imposing a code of conduct helps.
It's not unreasonable to believe that one or both of those are false.

If a COC stops people from contributing because they think their contribution (docs, PR, code, design, etc.) is offensive, then perhaps you don't need that contribution?
Saying you won't participate because the project is being too politically correct is a bit silly. I've yet to see a project where the CoC was used to harass contributors. It's simply a way for maintainers to tell people they won't tolerate douchebags.

To topic:
CoC's do work as a troll determent. On most OSS projects I've contributed to the CoC is used to isolate "code politics" from actual code.
Many large OSS projects do not have a CoC, the owner would just close/lock issues when they get out of hand.
IMHO a CoC adds a baseline (constitution) on which political issues can be "fairly" resolved.
Off topic:
A CoC might help with future discussions like this one :tada:
The NCoC is blunt.

@kballard

[...] a Code of Conduct isn't a set of absolute rules enforced by a robot and triggered by someone claiming offense, but is in fact a set of guidelines that are enforced by human moderators (e.g. project authors or community moderators) and are therefore subject to human interpretation.

That it is "subject to human interpretation" could be seen as a problem.

For a license to effectively serve its purpose, its terms must be unambiguous.
For a readme to be effective, it must provide unambiguous instructions.

Is a Code of Conduct an exception? Maybe it is. Can we explore that?
@jrobeson

Because I can't trust people to act like adults.

Agreed, though a Code of Conduct does not actually prevent people from acting like dicks.
@kballard

The only people that would be driven away by a CoC are people who recognize that they will likely violate it, and are therefore the people that the CoC is intended to protect the community from (which is to say, the CoC is doing its job). And you'll find plenty more people who will be interested in participating in a large part because the CoC exists and makes them feel like it's safe to participate.

I can't agree with this. What data are you drawing either of these conclusions from?

I would view an explicit No Code of Conduct as a statement that politics and prejudices can be left at the door. A Code of Conduct is political in nature. It happens to be a set of ideals that I agree with, but it isn't about "no politics I object to", is it?

A license is a legal document. A readme is a set of instructions. A Code of Conduct is neither of these things. And no, I don't think it's appropriate to "explore that", because that doesn't make sense. At best, asking to explore this avenue shows a bizarre tendency to view the world as though it's a computer program where everything must be explicit and unambiguous such that a computer can perform the job, which is wildly inappropriate when talking about moderating social discussions. And at worst it suggests a deliberate attempt to sabotage the CoC by trying to cast doubt on its validity however you can.

Agreed, though a Code of Conduct does not actually prevent people from acting like dicks.

No, moderators do that. But a Code of Conduct is a very valuable tool both for moderators and for self-policing of community forums. For moderators, a Code of Conduct is a document that moderators can point to when moderating both to show that the rules were posted (because many people believe that a lack of posted rules is a license to be a dick) and to shut off the inevitable discussions about whether the moderator was justified in enforcing a particular rule. And for self-policing, it empowers non-moderators to tell people when they're violating the rules (which is very important, because without this, people who are common targets for harassment or marginalization or who aren't confident enough in their social status in the group to speak out will tend to just stop participating when faced with the kind of behavior that the CoC is meant to stop).

The only people that would be driven away by a CoC are people who recognize that they will likely violate it, and are therefore the people that the CoC is intended to protect the community from (which is to say, the CoC is doing its job). And you'll find plenty more people who will be interested in participating in a large part because the CoC exists and makes them feel like it's safe to participate.
I can't agree with this. What data are you drawing either of these conclusions from?

Lots of personal experience in participating in public communities, both on my part and on the part of my wife (who is a moderator of a large default subreddit and deals with this kind of stuff all the time, and has been involved in various tech-related communities that inevitably have to deal with this sort of thing), as well as discussions with her and with other woman or other marginalized groups that face the issues that the CoC is expressly intended to deal with.
More to the point, why can't you agree with this? What reason is there to disagree with a public statement about what kind of behavior is not acceptable in the community, especially when, if I asked you about each specific example of bad behavior in the CoC, I expect you'd agree that that behavior does not belong in the community? The only reasons I can think of for not wanting this sort of thing actually spelled out are

You think you might actually violate the CoC.
You feel uncomfortable acknowledging that there are people that harass other people and would prefer to pretend the problem doesn't exist.
You've bought into the whole "meritocracy" bullshit, which is really just a flimsy justification for letting people be dicks because ability to write code trumps everything else and you think that just because you feel confident enough to continue participating in a community in the face of bad behavior by other members, that this means that everyone should do the same (i.e. if you think that the right response to bad behavior is to "grow a thicker skin" instead of stopping the bad behavior).

I would view an explicit No Code of Conduct as a statement that politics and prejudices can be left at the door.

You'd be completely wrong. An explicit "No Code of Conduct" is a statement that says that the project has explicitly chosen to exclude everyone who does not want to participate in a toxic community. It's a statement that says "If you want to harass people, by all means go ahead, we've chosen not to forbid that". It's a statement that says "this is a moderation-free zone". And perhaps worst of all, with a statement like this, you'll never know who chose not to participate in the project as a result, because they'll never even try.

A license is a legal document. A readme is a set of instructions. A Code of Conduct is neither of these things. And no, I don't think it's appropriate to "explore that", because that doesn't make sense. At best, asking to explore this avenue shows a bizarre tendency to view the world as though it's a computer program where everything must be explicit and unambiguous such that a computer can perform the job, which is wildly inappropriate when talking about moderating social discussions. And at worst it suggests a deliberate attempt to sabotage the CoC by trying to cast doubt on its validity however you can.

Your response is exactly what I was asking for: Exploring how a Code of Conduct may legitimately be a different case than a license or readme. I'm confused by your response, and the conclusions you're drawing from my query.

Agreed, though a Code of Conduct does not actually prevent people from acting like dicks.

No, moderators do that. But a Code of Conduct is a very valuable tool both for moderators and for self-policing of community forums. For moderators, a Code of Conduct is a document that moderators can point to when moderating both to show that the rules were posted (because many people believe that a lack of posted rules is a license to be a dick) and to shut off the inevitable discussions about whether the moderator was justified in enforcing a particular rule. And for self-policing, it empowers non-moderators to tell people when they're violating the rules (which is very important, because without this, people who are common targets for harassment or marginalization or who aren't confident enough in their social status in the group to speak out will tend to just stop participating when faced with the kind of behavior that the CoC is meant to stop).

Providing a clear set of rules that community members can use for reference is a practical benefit to having a Code of Conduct.

The only people that would be driven away by a CoC are people who recognize that they will likely violate it, and are therefore the people that the CoC is intended to protect the community from (which is to say, the CoC is doing its job). And you'll find plenty more people who will be interested in participating in a large part because the CoC exists and makes them feel like it's safe to participate.

I can't agree with this. What data are you drawing either of these conclusions from?

Lots of personal experience in participating in public communities, both on my part and on the part of my wife (who is a moderator of a large default subreddit and deals with this kind of stuff all the time, and has been involved in various tech-related communities that inevitably have to deal with this sort of thing), as well as discussions with her and with other woman or other marginalized groups that face the issues that the CoC is expressly intended to deal with.

That provides some context, thank you.

More to the point, why can't you agree with this? What reason is there to disagree with a public statement about what kind of behavior is not acceptable in the community, especially when, if I asked you about each specific example of bad behavior in the CoC, I expect you'd agree that that behavior does not belong in the community?

Aha, I think this is where I gave offense. I can see how my prior response wasn't clear in what I couldn't agree with.

The only people that would be driven away by a CoC are people who recognize that they will likely violate it, and are therefore the people that the CoC is intended to protect the community from (which is to say, the CoC is doing its job).

There are two main issues I take with this statement, aside from the fact that it's a sweeping generalization.
Trolls are attracted to places where they can stir the pot. I want to believe that the influx of good people encouraged by a Code of Conduct outweighs the number of trolls who see it as "I can rustle some jimmies over there".
I'm really not sure which is the case, though. So I can't agree that your statement is accurate.
It also discounts signal-to-noise as a factor in community engagement. I think that there are some people whose first exposure to a community is the meta-discussion, and who may not look beyond that.
You mention personal experience with Reddit. I assume you've seen communities devolve into a pile of meta-discussions about moderation and community management, and the predictable splintering into some r/true[true[true]]<subject> subcommunity.
Please don't read this point as dismissing all the times where this isn't the case. I'm pretty sure I've seen more good come from responsible community moderation than harm, with a handful of edge cases.

And you'll find plenty more people who will be interested in participating in a large part because the CoC exists and makes them feel like it's safe to participate.

I really wish we had some data to support this as a net gain. This could be a valuable side project! There's a massive pile of data sitting here on GitHub, we just need to find enough projects with a Code of Conduct, and figure out what reasonable indicators are for this. I'd be up for contributing to this, if someone wants to organize it. I'm cozy with the GitHub API and data processing.

The only reasons I can think of for not wanting this sort of thing actually spelled out are
You think you might actually violate the CoC.

I find my personal views align quite strongly with the ideals described in Codes of Conduct like this one.

You feel uncomfortable acknowledging that there are people that harass other people and would prefer to pretend the problem doesn't exist.

I'm quite aware that humans can be absolutely terrible to each other.

You've bought into the whole "meritocracy" bullshit, which is really just a flimsy justification for letting people be dicks because ability to write code trumps everything else and you think that just because you feel confident enough to continue participating in a community in the face of bad behavior by other members, that this means that everyone should do the same (i.e. if you think that the right response to bad behavior is to "grow a thicker skin" instead of stopping the bad behavior).

I think you're coupling several disconnected concepts here.  Similarly, no person should be expected to endure cruelty at the hands of another, under any circumstances. Meritocracy does not advocate either of these things.

I would view an explicit No Code of Conduct as a statement that politics and prejudices can be left at the door.

You'd be completely wrong.

Well, no... that's not how it works. That is how I would read it, biased by my personal experiences (for better or worse). It's completely reasonable that someone else may read it differently.

An explicit "No Code of Conduct" is a statement that says that the project has explicitly chosen to exclude everyone who does not want to participate in a toxic community. It's a statement that says "If you want to harass people, by all means go ahead, we've chosen not to forbid that". It's a statement that says "this is a moderation-free zone". And perhaps worst of all, with a statement like this, you'll never know who chose not to participate in the project as a result, because they'll never even try.

And this is where you lost me. I've read the NCoC over several times to try to find where it says these things. In fact, the following sections explicitly state that moderation can and will happen in an NCoC project.

Q: As a community manager or leader, what happens when the mob arrives, or when someone starts to engage in discussion that could lead to more endless discussion?
Lock, and ban your way to freedom. This is unfortunate. Try to not delete anything, or you will be accused of censorship. But you have no other choice. Do not engage. Abort, abort abort! You should really be very brief, vague, and closed off in these discussions. Say something like: "hey, this is not the place to discuss this, please reach out to each other privately or on another medium to discuss it. This group is strictly about topics relating to $YOUR_TOPIC". End.
Q: WTF, the discussion was locked, and/or I can't reply!?
Once again, we are not going to tolerate our community being overridden by the mob. If this starts to happen, we will nuke, delete, lock, close, ban, and do whatever we have to do to put the fire out. These discussions drag on and on and on, and they don't make communities better.

Trolls are attracted to places where they can stir the pot. I want to believe that the influx of good people encouraged by a Code of Conduct outweighs the number of trolls who see it as "I can rustle some jimmies over there".

This response confuses me, because that's just not something that happens. Codes of Conduct are not things that attract trolls; they are in fact the exact opposite, they're a very valuable tool in fighting trolling (because trolling often ends up violating the CoC and provides clear grounds for deleting posts / banning trolls). Without a Code of Conduct, trolls can often continue trolling by complaining about previous moderation, and complaining about other people accusing them of bad behavior. But the Code of Conduct provides a clear way for moderators to justify their actions, which immediately shuts down any attempted meta-trolling.

You mention personal experience with Reddit. I assume you've seen communities devolve into a pile of meta-discussions about moderation and community management, and the predictable splintering into some r/true[true[true]]<subject> subcommunity.

That's a symptom of poor moderation, not a consequence of having a code of conduct. And of course having no moderation at all leads to people abandoning the community just as much, if not more-so, than having bad moderation.

I think you're coupling several disconnected concepts here.  Similarly, no person should be expected to endure cruelty at the hands of another, under any circumstances.

I'm glad to hear you say that.

Meritocracy does not advocate either of these things.

Actually it does. It doesn't sound like it means that, but that is in fact the consequence of saying that the only thing that matters is ability. Because saying that only ability matters also means saying that nothing else matters, which includes how you behave.

I would view an explicit No Code of Conduct as a statement that politics and prejudices can be left at the door.
You'd be completely wrong.
Well, no... that's not how it works. That is how I would read it, biased by my personal experiences (for better or worse). It's completely reasonable that someone else may read it differently.

I'm not saying you wouldn't interpret it that way, I'm saying that interpretation would be wrong, because it wouldn't match the reality of what would happen as a result of having that statement.

An explicit "No Code of Conduct" […]
And this is where you lost me. I've read the NCoC over several times to try to find where it says these things. In fact, the following sections explicitly state that moderation can and will happen in an NCoC project.

But that's the point; it doesn't say anything at all, except that the project moderators have recognized the concept of a Code of Conduct and explicitly chosen not to have one. The NCoC is a very intentional statement of having no code of conduct. The project README may talk about moderation happening, but that's not actually a part of the NCoC in any way. The NCoC does not help moderation in the slightest bit. And the issues the README are talking about are things that are much easier to deal with if you have an actual CoC in place instead of that stupid statement saying you have No Code of Conduct.

Trolls are attracted to places where they can stir the pot. I want to believe that the influx of good people encouraged by a Code of Conduct outweighs the number of trolls who see it as "I can rustle some jimmies over there".

This response confuses me, because that's just not something that happens. Codes of Conduct are not things that attract trolls; they are in fact the exact opposite, they're a very valuable tool in fighting trolling (because trolling often ends up violating the CoC and provides clear grounds for deleting posts / banning trolls). Without a Code of Conduct, trolls can often continue trolling by complaining about previous moderation, and complaining about other people accusing them of bad behavior. But the Code of Conduct provides a clear way for moderators to justify their actions, which immediately shuts down any attempted meta-trolling.

I think you're falling into the trap of believing that trolls care about or play by the rules.

Meritocracy does not advocate either of these things.

Actually it does. It doesn't sound like it means that, but that is in fact the consequence of saying that the only thing that matters is ability. Because saying that only ability matters also means saying that nothing else matters, which includes how you behave.

If you reduce the notion of meritocracy to a single point, then I can understand how you could arrive at those conclusions. Accepting that premise for the sake of discussion, is it actually wrong in the context of a contribution?
Does the character of the individual give more or less weight to the validity of their contribution? Consider two extreme cases (acknowledging that things will rarely be this simple):
If Alice's code is untested, dangerous, poorly implemented, or in conflict with the current design or roadmap of the project she is contributing to, all the good behaviour in the world doesn't make it okay to merge that change.
It does make it easier to work together to resolve the technical issues, though.
If Bob's code is thoroughly tested, implemented skillfully and clearly, and solves a real need (fixing a bug, implementing a feature, etc), and he contributes that code to the project under the accepted license, should that contribution be rejected, because Bob is a dick?
While it would be challenging to work with Bob, in this example the required collaboration is deliberately minimal.

But that's the point; it doesn't say anything at all, except that the project moderators have recognized the concept of a Code of Conduct and explicitly chosen not to have one. The NCoC is a very intentional statement of having no code of conduct. The project README may talk about moderation happening, but that's not actually a part of the NCoC in any way. The NCoC does not help moderation in the slightest bit. And the issues the README are talking about are things that are much easier to deal with if you have an actual CoC in place instead of that stupid statement saying you have No Code of Conduct.

With or without a Code of Conduct, warnings, blocks, and thread locks remain effective tools for moderation.

As for what I actually believe on this subject?
I agree in spirit with the Code of Conduct, but I don't have enough data to state with confidence that it has any quantifiable impact. That said, I don't think it actually does any harm.
I view the intent of NCoC quite differently from how you do, and that's probably worth highlighting.
It's difficult to predict what others will interpret something as, and discussions like this one help get a larger sampling to understand how a decision will be viewed, beyond the intention of the person making that change.
I'd vote for no change, and suggest we revisit the subject if it ever becomes a problem in the future.

if bob is hard to work with while doing code reviews and such, then his code might not be acceptable to be merged, as then he wouldn't be worth dealing with when it comes to issues that might crop up when the code is actually in use and causes bugs.

@jrobeson I hadn't considered it from that perspective. Thanks!

My perspective is that maintaining software (or more specifically FOSS) is a team sport. Thus, I like to be able to choose my teammates based not just on ability, but whether they might be fun to work with. FOSS is really hard, why make it harder by putting up with people who make your life difficult.

I've been working with FOSS for quite some time ( > 10 years), and as time as gone on, finding good people to work with is harder than finding good code.

@jrobeson Agreed. I think that's the difference between communities and projects that accept contributions.

considering how quickly personal projects can turn into communities, it is a very blurry line.

One of the amazing things about git is how it makes all of this irrelevant.
Don't like how someone talked to you?  Ignore them.
People don't want to merge your code?  Fork the project.
Find a fork you like better?  Contribute to it instead.
Fork merges good code without sending you a PR?  Merge it yourself.
We're talking about software here.  The only thing necessary to allow people to cooperate is an API.  It doesn't matter whether people like each other or are nice to each other--for whatever definition of "nice."
Imagine if the entire FOSS ecosystem had one giant repository and one monolithic code of conduct.  Someone in the X.org tree mouths off to someone in the Linux tree, they get excluded, no more contributions to X from them.  Someone in Mozilla takes their side, flames someone in LibreOffice who took the other side, both of them get banned; Firefox and LibreOffice lose contributors.  Someone in the OpenBSD tree gets offended at a statement by RMS, no more OpenSSH for GNU/Linux.  Etc, etc.
Thankfully, it doesn't work that way.  You don't like someone?  Someone doesn't like you?  Oh well.  Ignore them or fork the project.  People use whichever one is technically superior.  The software moves on.  It's the people who get hung up on things.
The limiting resource for all of us is primarily time.  And it's a shame that so much of it gets wasted on arguments like these: arguments about hypothetical future arguments.
This is why the argument that software projects should just focus on technical issues is so strong.  Imagine if every GitHub project with multiple contributors had to sit down and debate and decide on its own code of conduct.  Then imagine if one person who contributed to 50 projects offended people in 10 projects.  Does that mean that the leaders of those 10 projects now are required to "investigate" this person and police his private communication with other people?  Don't they have more important things to do, like write and review code?  Does every repo on GitHub need its own enforcement officer and investigative authority?
How did the Internet survive until this point?  How did USENET get by?  Eternal September was a long time ago--how did we get here?
Oh well.  Carry on.

using usenet as any part of an argument proves the point. Usenet was a hive of scum and villainy.

@alphapapa That's a very exclusionist position to take. Yes, theoretically people can fork the project and go their own way, but in practice that happens extremely rarely, because either your fork doesn't have any community support, or it does gain community support and therefore splits the community (which is a great way to kill off projects). Even ignoring all that, most people, when confronted with a project that is exclusionary (either deliberately excluding them, or unintentionally turning people away by having a non-welcoming community), will simply abandon the project. And that doesn't just mean the person won't use the project, it also means the project just lost a potential contributor.
Not only that, but by having a community that takes this attitude, you're ensuring that the only people that will participate in the community are people exactly like you, people who don't have to deal with harassment and discrimination online (e.g. due to gender, sexuality, or ethnicity), and who aren't discouraged by non-welcoming communities. Similarly, you're also probably turning away less experienced contributors, people who could be valuable members of the community but don't feel confident enough in their skills to be willing to put themselves out there and publicly contribute something. This also means that you're discriminating against women and disadvantaged minorities (both because members of those groups are more likely to be less experienced, and much more likely to experience harassment online).

Imagine if every GitHub project with multiple contributors had to sit down and debate and decide on its own code of conduct.

That's a straw man. The only debate that happens is because of people like you who are arguing against the whole idea of having a Code of Conduct. There's no need for projects to actually debate their code of conduct at all, all that's needed is for the project maintainer to say "we have a code of conduct, and that's final".

Then imagine if one person who contributed to 50 projects offended people in 10 projects. Does that mean that the leaders of those 10 projects now are required to "investigate" this person and police his private communication with other people?

Required? Required by whom? Each community can decide on its own how it wants to handle moderation. But moderation is required, whether or not you have a code of conduct, and pretending it's a consequence of having a code of conduct is disingenuous. And as I've said before, having a code of conduct makes moderation easier, not harder as you're implying here.

Don't they have more important things to do, like write and review code?

If one community member is harassing other community members, then no, they don't have more important things to do, because refusing to moderate your community is a great way to destroy it, or at least to end up driving away most potential contributors. If you want to have pull requests to review, you need to have people to submit the pull requests, and if you drive away your contributors, they aren't going to be submitting pull requests.

I personally avoid contributing to projects in my free time that explicitly turned down a code of conduct.

One of the amazing things about git is how it makes all of this irrelevant.

Huh? Git is a version control system. It's perfectly possible to be completely rude and out of line towards people while using git.

@daenney : the argument is that since git is decentralized, that you can just walk away to avoid dealing with people who cause problems. I think that argument is way too simplistic, but that's what the point of it is.

Sense to me, it makes none.

I think we can all agree that keeping the CoC would be preferred to losing it.

by having a community that takes this attitude, you're ensuring that the only people that will participate in the community are people exactly like you

I hope it's self-evident to people how preposterous a statement that is.  This is the Internet.  You don't know anything about me, and I don't know anything about you.  You don't know what I'm like, and I don't know what you're like--nor does it matter to me.
Public communities on the Internet are incredibly diverse.  The possibility of anonymity makes the diversity even greater than anyone could know.  The only communities on the Internet that are made up of people who are exactly alike are those which explicitly exclude others.
And not having a code of conduct does not explicitly exclude anyone.  In fact, by not explicitly excluding anyone, it leaves open the door to the widest possible participation, i.e. the most inclusive community possible.
Conversely, having a code of conduct explicitly threatens punishment and exclusion from the community.  And that is a clear deterrent against participation, especially as it implies discrimination against those who hold unpopular views.
In the end, a community that chooses this path declares that it's more interested in politics and feelings than in software and technical excellence.  It's more interested in leading by instilling fear of exclusion than leading by example of excellence.
And you know what?  That's fine.  Like I said, that's one of the greatest things about the Internet, git, etc: there's no shortage of room for virtual communities.  People who want to create walled gardens can do so, and they can exist simultaneously with open spaces.  They can all co-exist in time and space, overlapping visibly and invisibly.  People can choose freely whom they wish to participate with.
May we never lose our appreciation for this greatest of assets: freedom.

@alphapapa So are you in favor of removing the CoC or against it?

Seems like he is vehemently against a code of conduct.

@bucaran Well, it's your project, so I don't suppose it matters what I think.  :)
Please don't misunderstand me: I'm not in favor of treating anyone badly for any reason.  I've run online communities before (a long time ago, now), and we had rules against mistreating people.  And those rules helped to keep out trolls and create a friendly community.
But things have changed.  The kinds of codes of conduct that are being pushed by certain groups online now are politically motivated.  Instead of being blanket statements against treating people badly, they invoke political ideologies.  Instead of defusing controversy, they cause it.  They claim to be inclusive by being exclusive.  Instead of a community leading by example, being patient and tolerant and showing people a better way by gently discouraging bad behavior and demonstrating good behavior, the codes threaten punishment and excommunication.
Instead of recognizing that the world is a diverse place with a variety of cultures, and encouraging people to give others the benefit of the doubt regarding their intention, the codes assume bad faith on the part of speakers, and empower hearers to impart guilt onto speakers.  Instead of recognizing that a multiplicity of online communities overlap in time and space and membership, the codes attempt to reduce behavior toward a lowest-common-denominator.  Instead of fostering an atmosphere of open, honest communication, the codes create an air of suspicion and doubt, instilling fear and causing people to constantly be on guard against saying anything that could be misconstrued or--quite frankly--disagreed with.
IMO, these codes also fail to recognize that software communities and projects are unique among other types of communities.  Not only are they mostly virtual, but they exist for the purpose of creating something useful, which, in the case of FOSS projects, exists outside of their communities and outlive them.
People who have wildly divergent political and social values can still collaborate on technical projects.  And, indeed, this has been the case ever since the Internet began.  It's only recently that some people have been trying to push political agendas into the technical arena.
Perhaps the best code of conduct would be one that said something like, "This is a technical project.  Leave political, religious, social, or sexual issues at the door.  Private communication between group members is not a concern of the project.  Statements made by project members as private citizens or as members of other, unrelated projects is not a concern of the project.  Disagreements between project members over issues unrelated to the project should be resolved privately."
When people treat other people badly, it's not a matter of rules or regulations--it's a matter of the heart.  And the heart is not so easily converted by a code of conduct.  The heart is converted by loving, patient example over a period of time.
Well, since you asked for it, there's my two (more) cents.  :)  Like I said, it's your project, so it's up to you.  Good luck to all of you.

This is a technical project. Leave political, religious, social, or sexual issues at the door. Private communication between group members is not a concern of the project. Statements made by project members as private citizens or as members of other, unrelated projects is not a concern of the project. Disagreements between project members over issues unrelated to the project should be resolved privately.

I like that. What is the one thing about the current CoC that you think should be removed? I think we can move faster if we attack specific points rather than discussing this in such an abstract manner.

It sounds like @alphapapa wants something more akin to the NCoC.
FWIW, The newer version of the CoC this project uses has been much more amenable to people's sensibilities from what I've seen. Maybe worth looking at that?

@alphapapa Spoken like someone who's never had to deal with online harassment.

The kinds of codes of conduct that are being pushed by certain groups online now are politically motivated. Instead of being blanket statements against treating people badly, they invoke political ideologies.

Please point to an example of this.  No code of conduct I've ever seen matches this description.

Instead of defusing controversy, they cause it.

No, what causes it is people like you who keep arguing for the right to exclude everyone who don't feel comfortable participating in a community that refuses to have rules against harassment and other bad behavior.

They claim to be inclusive by being exclusive.

That's nonsense. The only people it excludes are people who won't follow the code of conduct, and those are the people that don't belong in the community. Or to put it another way, anyone excluded by the code of conduct deserves to be excluded because they're persistently engaging in unwanted behavior.
 It's so twisted that I can't believe you actually genuinely believe this, and quite frankly I think you're intentionally making up this wild mischaracterization without any basis in reality. For example:

the codes create an air of suspicion and doubt

Not even remotely true. I've been a member of many communities with various codes of conduct, and the code of conduct has never caused anything even the slightest bit like this. In fact it's quite the opposite, communities with codes of conduct are places where people can feel safe to participate, and where the atmosphere ends up being much more welcoming, inclusive, and tolerant than other communities.
@bucaran

What is the one thing about the current CoC that you think should be removed or you don't like?

Don't remove anything. Private harassment done in the context of this project should absolutely be grounds for punitive action against the harasser (could just be the project author saying "cut it out", or it could escalate to banning someone from the community). Obviously the project author cannot actually prevent the harasser from continuing the harassment, but they can make it clear that such behavior is not welcome in the community.
If you explicitly choose to take out the mention of private harassment, the message that sends is that the community doesn't actually care about being a safe place for everyone to participate but instead only cares about the appearance of that. And that's not something I can support.
Besides, the concerns about this are way overblown. There is no legitimate reason to think that having a policy that prohibits private harassment will cause any problem whatsoever.

@kballard I won't remove the CoC, as I can't see how not having one could improve anything. And if having a CoC is likely to attract less experienced users and other minorities to the project, then I'd add not one, but two CoC :smile:

@alphapapa Spoken like someone who's never had to deal with online harassment.

See, this just boggles my mind, because you literally know nothing about me.  I don't see how it's possible to have a reasonable discussion if you're going to make such speculation about me and then treat my point of view with contempt because of it.  Regardless of whether I have or not, are you not excluding me and declaring my experience invalid?  And isn't that the problem you're trying to solve?

No, what causes it is people like you who keep arguing for the right to exclude everyone who don't feel comfortable participating in a community that refuses to have rules against harassment and other bad behavior.

This also boggles my mind.  Everything I've said has advocated for being inclusive of all, and avoiding excluding anyone.
There is something you don't seem to understand: if a person chooses to not participate in a community because that community doesn't have a certain policy they desire, that community is not excluding that person--that person is choosing to not participate in that community.
You're basically accusing this hypothetical community of excluding people because they refuse to exclude people.  This just doesn't make sense.  Anyone who chooses to participate or not does so of their own free will.
And by painting people who disagree with you as "arguing for the right to exclude everyone," you seem to be trying to vilify people who disagree with you and pressure people to take your side.  It seems like some kind of extortion, saying, "If you don't have a policy that excludes people I don't like, you're excluding me."

That's nonsense. The only people it excludes are people who won't follow the code of conduct, and those are the people that don't belong in the community. Or to put it another way, anyone excluded by the code of conduct deserves to be excluded because they're persistently engaging in unwanted behavior.

The problem is that "unwanted behavior" is a matter of opinion, and interpretations vary wildly throughout the world.
Personally, I find it problematic when anyone takes it upon himself to say that someone "deserves to be excluded."  Human beings share one universal trait: fallibility.  We all make mistakes, we all do wrong things, and we all fall short of the standards to which we should aspire.  We all "deserve to be excluded" because we all have done wrong.  A greater value than exclusion is mercy; we should aspire more toward that.

 It's so twisted that I can't believe you actually genuinely believe this, and quite frankly I think you're intentionally making up this wild mischaracterization without any basis in reality. For example:

It's hard for me to take you seriously when you are so rude.  Frankly, it would not be a stretch, were I so inclined, to consider your tone harassing--in which case, would you be guilty and therefore in need of sanction and exclusion?  Do you see how quickly and easily it escalates?  And who's to say where the line is to be drawn?  You're illustrating the problem quite well.

Not even remotely true. I've been a member of many communities with various codes of conduct, and the code of conduct has never caused anything even the slightest bit like this. In fact it's quite the opposite, communities with codes of conduct are places where people can feel safe to participate, and where the atmosphere ends up being much more welcoming, inclusive, and tolerant than other communities.

Okay.  I'm not declaring your experience invalid.  Are you declaring mine invalid?  Do you recognize that your experience is not universal?  I would submit this discussion as evidence that trying to enforce codes of conduct can have negative effects.

Don't remove anything. Private harassment done in the context of this project should absolutely be grounds for punitive action against the harasser (could just be the project author saying "cut it out", or it could escalate to banning someone from the community). Obviously the project author cannot actually prevent the harasser from continuing the harassment, but they can make it clear that such behavior is not welcome in the community.

What does "in the context of this project" mean?  Does it mean that any two people who participate in this project aren't allowed to vehemently disagree with each other in private email?  Does it mean they aren't allowed to insult each other, or even hate each other, for reasons completely unrelated to the project?  What business is it of the project's?
I just don't understand how creating a new repo on GitHub creates a responsibility or authority to monitor participants' private communication.  Let's say that person A curses at person B in a private email because of prejudice against his skin color, and project A bans person A.  Now person A is also a participant in project B, but person B is not.  Is project B required to ban person A as well?  What about project C, in which person B is a participant, but not person A: is project C required to preemptively ban person A from future participation?  Should there be a global GitHub banlist?  Should projects be required to use it?  Who decides when person A is eligible to participate again?

If you explicitly choose to take out the mention of private harassment, the message that sends is that the community doesn't actually care about being a safe place for everyone to participate but instead only cares about the appearance of that. And that's not something I can support.

That's not the message I think it sends.  I think it sends the message that the project is more concerned about policing participants' opinions and private communications, which are none of the project's business, than it is about making good software.  Conversely, saying that private communications are the concern of nobody except the people directly involved, is to maintain a technical focus and, importantly, to respect participants' privacy.
Personally, I could not support a policy which assumed an authority or responsibility to violate participants' privacy.

Besides, the concerns about this are way overblown. There is no legitimate reason to think that having a policy that prohibits private harassment will cause any problem whatsoever.

You can dismiss opposing views as illegitimate, but that does not make them so.
I think this discussion illustrates the problems inherent in such a policy, and the project would be well-served to adopt a policy of "technically minding its own business."  :)

And not having a code of conduct does not explicitly exclude anyone. In fact, by not explicitly excluding anyone, it leaves open the door to the widest possible participation, i.e. the most inclusive community possible.

Conversely, having a code of conduct explicitly threatens punishment and exclusion from the community. And that is a clear deterrent against participation, especially as it implies discrimination against those who hold unpopular views.

Couldn't disagree with this more.  Having a code of conduct ensures that your community will be inclusive, technically-oriented, and not maligned by bullies/trolls/those-with-unpopular-views.

@bucaran : since you've decided, you might as well mark this issue as closed, and maybe lock if you don't plan on changing your decision

@jrobeson Thanks. Yep. I was about too.
Alright, folks, thanks for this wonderful and insightful discussion. Multiple points of views is what make discussions interesting. If we were all simply repeating how the other is so right about that or this, it would be very weird.
We will keep the CoC.


Added Dockerfile

See issue: https://github.com/ParsePlatform/parse-server/issues/110

Since this is just the router package, and not a full server, I think the Dockerfile should reside in parse-server-example.  I just merged a PR there which added it.


Transition to unified V2 API

API Base URL - https://api.micronutrient.support/v2/
API Docs - https://api.micronutrient.support/docs/core-data-api/reference
Updated routes - Sidebar
List countries /countries
List micronutrients /micronutrients
Diet data Sources /diet/data-sources (Pass country ID and Micronutrient ID)
Biomarker data sources biomarker/data-sources (Pass country ID and Micronutrient ID)
Update routes - Projections

Update routes - Diet Data

Monthly foods and household dietary supply routes TBC

is this complete @jon571  and can be closed?

Not quite.  The old route is still being used by one component and I'm working on chopping that stuff out now. :-)

API endpoints now utilised:

/diet/country/availability
/diet/country/top-foods
/diet/data-sources
/diet/household/availability
/diet/household/top-foods
/biomarker/age-gender-groups
/biomarker/data-sources
/diet/projections/commodities
/diet/projections/food-groups
/diet/projections/scenarios
/diet/projections/summaries
/diet/projections/totals
/countries
/micronutrients

It doesn't look like any other endpoints are available, so I'll leave it here and mark this task as complete.


Recline still alive?

Not a lot of activity going on, just wondering if this is still a live project?

@christophersbarrett people are still here but i would say most development from my (and @okfn) perspective has moved to Frictionless Data tools that cover a lot of this. E.g. most of https://datahub.io is built using that toolchain -- see e.g. graph on https://datahub.io/core/gold-prices. More docs about this at https://datahub.io/docs/features/views and https://github.com/frictionlessdata/datapackage-render-js

@rufuspollock Is there a "multiview" setup for the frictionless data views similar to Recline? If not is there a ticket or desire to create that?

@acouch we have something like this but simple in datahub.io where we render the views side by side.

FIXED. Recline is getting updated and evolved see #520


Why can't the value in add_attribute be “”?

pub fn execute_set_round_info(
    deps: DepsMut,
    _env: Env,
    info: MessageInfo,
    round_info: RoundInfo,
) -> Result<Response, ContractError> {
    if !can_execute(deps.as_ref(), info.sender.as_ref())? {
        Err(ContractError::Unauthorized {})
    } else {
        ROUNDINFO.save(deps.storage, &round_info)?;

        Ok(Response::new()
            .add_attribute("action", "set_round_info")
            .add_attribute("title", round_info.title)
            .add_attribute("description", "".to_string())  // <- Why can't the value in add_attribute be ""?
            .add_attribute("link", round_info.link))
    }
}

Yes, that's the error I linked. You can create an issue in the wasmd repo

Closing in favour of https://github.com/CosmWasm/wasmd/issues/1617


[Event Request] Codeunit 370 "Bank Acc. Reconciliation Post"

Hi Team,
BC version - 18.3.27240.27381;
codeunit - 370 "Bank Acc. Reconciliation Post" ;
procedure - TransferToPostPmtAppln (the same event could be adde to the similar function TransferToBankStmt);
We would like to have an event (for example OnBeforePostedPmtReconLineInsert) before inserting "Posted Payment Recon. Line" from "Bank Acc. Reconciliation Line" while posting Payment Reconciliation Jnl. to have more control.

[IntegrationEvent(false, false)]
local procedure OnBeforePostedPmtReconLineInsert(var PostedPmtReconLine: Record "Posted Payment Recon. Line"; BankAccReconLine: Record "Bank Acc. Reconciliation Line")
begin
end;

You help us implementing the requests faster when your request contains AL code copied from VSCode instead of screenshots.

You help us implementing the requests faster when your request contains AL code copied from VSCode instead of screenshots.

Got it, will follow this rule in future requests.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


remove "?style=flat" in badge link

Remove "?style=flat" in badge link, because it's unnecessary!

style
badge

with "?style=flat"

without "?style=flat"

Oh yeah, I believe it used to be flat-square so it might be residue from when someone changed that.

Thanks!

Flat didn't used to be the default style, but glad it is now :)


Which versions of GHC should we support

Right now the application is tested with GHC 7.6.3, 7.8.4, and 7.10.1. Should we still worrying about GHC 7.6.3? If so, we could continue using cabal in travis, otherwise we could switch to stack, and also we could use hspec-discover instead of one file that calls the other test modules.
This issue should be consider in the other OS projects.

@CristhianMotoche 7.8 (7.8.4) and 7.10 (7.10.3) sounds good to me.

I'll close this issue, since #24.


Update Typescript.

This CR updates Typescript to version 3.8.3,
@types/node to version 14.11.8,
ts-node to version 9.0.0
Resolves: OLPEDGE-2315
Signed-off-by: Oleksii Zubko<EMAIL_ADDRESS>

Codecov Report

Merging #382 into master will not change coverage.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             master       #382   +/-   ##
===========================================
  Coverage   88.0933%   88.0933%
===========================================
  Files            71         71
  Lines          2402       2402
  Branches        264        264
===========================================
  Hits           2116       2116
  Misses          161        161
  Partials        125        125

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d2715a0...513fd89. Read the comment docs.


Normalization

This plugin is awesome but I'm missing the normalization feature available in NAM plugin, which normalizes only the NAM block even when not using the IR block.
Also, the actual normalization Ratatouille has does something weird: When I load a very quiet IR (~ -16 dB peak), it sounds ultra loud when Normalization is active.
IR file stats:

IR loaded on NadIR (normalized):

IR loaded on Ratatouille:

IR loaded on Ratatouille (normalized):

Thank you for your awesome work!

Glad to hear it is useful. I've implemented normalization for NAM models now. Note that it only works with models providing the loudness factor.
To the normalization of the IR files, it is done to adjust the loudness of IR files to the same level. So, when you switch a IR file it shouldn't have any influence on the output level.
It is clear that a quit IR file become louder while a loud IR file become more quieter.
I must admit that the curves you presented didn't look right. Still, I like to ask when you switch IR files, do you get a different output level?

Glad to hear it is useful. I've implemented normalization for NAM models now. Note that it only works with models providing the loudness factor.

Awesome, thank you very much. Given the amount of different normalizations available, just to  be clear, in my first point I was talking about output normalization, which can be set here, in NAM:

I understand that Ratatouille uses RAW mode, which is great already. So, in my first point I was talking about the "Normalized" option, available for all models even when there's no metadata. It's really useful as it makes up for different output capture setups.

It is clear that a quit IR file become louder while a loud IR file become more quieter.
Agreed

I must admit that the curves you presented didn't look right. Still, I like to ask when you switch IR files, do you get a different output level?
Yeah, very different.

Ratatouille first increases it to a higher level, then, with a normalized file (0 dB peak IR), normalization will bring it back to an "around zero" value:

Maybe it doesn't need to be increased first?
That quieter IR file.

With this file, that first increase already puts it "around zero" then when I set the normalization, it adds to makes it really loud.
Thanks!

Agreed

I must admit that the curves you presented didn't look right. Still, I like to ask when you switch IR files, do you get a different output level?

Yeah, very different.

I mean when you've normalisation active.

Ratatouille first increases it to a higher level, then, with a normalized file (0 dB peak IR), normalization will bring it back to an "around zero" value:

No, Ratatouille doesn't do such. It just load the IR file as it is (using libsndfile) into a buffer. When normalize is selected, it calculate the square root of the complete file and calculate a gain factor to bring that (the square root) to zero, so that when it is used in convolution it have no influence on the loudness.
Hence I wonder that you get different loudness  levels when normalisation is on and you switch a IR file.

Interesting. Maybe something with libsndfile as tThe same happens in ImpulseLoader. After convolution using Ratatouille or ImpulseLoader, a sample with peak 0 dB and an IR with peak 0 dB will be at around +20 dB.

As far I could see it only works in there as well only when the model provide the needed meta data.

Yeah, that's the one. You are right, the model must provide it. Much appreciated!

I don't think that there could be something wrong with libsndfile (given how wide it is used). I'll take the stab and rethink my normalisation function (there are so many way's to do it) as that should be more expected to be the culprit.
I mean, it works for me in all cases I've tested, but it seems you found some corner cases were it fail badly. I need to find out why.

I'm sending the IR file, maybe that could help. Meanwhile I'll take a look at the code to see if I find something. Thanks!
SM57_2.zip

Maybe when factor is less than 1, you get double the value.
I problably wrong, but to normalize, wouldn't it be necessary to divide the absolute value of each sample by the maximum peak value?
Something like that (pseudo code):
for each sample n:      magnitude(sample n) = abs(sample n)      normalized(sample n) = magnitude(sample n) / maximum_magnitune

Okay, the IR file helps.
My intention was to get the square root of the IR file to zero so that only the eq curve get applied. But my attempt only work's when the file level is above 1.
I've switched now to a simple normalisation formula to make it even work for all files. Downside is that we can't negate the loudness influence this way, but we could make it even, that's good as well I think.
Thanks for pointing out this issue, let me know if it works for you now the way you expected.

It works for all files now, thanks.
I think the loudness can be a problem, but since I have already caused you a lot of trouble, I'll try something and send a pull request later.

It may be a good Idea to reimplement my older loudness compensation algorithm just after the normalisation. So the normalisation ensure that the square root is above 1 and the loudness compensation works then for all files, as well when they comes with less loudness like your example file.

I've done some tests and it seems to work flawless now. So I pushed it to the repository.

I see you already fixed, not sure if it will get merged but here it is: https://github.com/brummer10/Ratatouille.lv2/pull/32

I've commented on the pull request. I see some issues with this optimisation so I can't merge it.
I guess what we could do is fetching the square root value in the same loop were we apply the normalisation factor, that will spare one loop.

I've changed the pull request so it sums the squared values of normalized buffer, like you said.
I did some tests and both methods work. The way I did it first, the factor made the IRs a 1-2 dB quieter than now. Maybe this is a coincidence, but nadIR seems to normalize 1-2 dB quieter as well.
Anyway, even though the method I used before is closer to other loaders (maybe by coincidence), I think it makes sense the way it is now: We first normalize the file for cases where the IR was created wihout normalization and then apply the loudness factor.

Nice. Thanks for your contribution, it's merged now.


Pass ClassName through to equalizer div

I've made this modification so an additional div will not be needed to apply a class to the equalizer group

Looks good mate.
One suggestion can you fix this up so it uses the spread operator so it will be generic and handle other props like styles etc... see https://facebook.github.io/react/docs/transferring-props.html.
Something like this:
updateChildrenHeights() {
    const { property, byRow, enabled, nodes, ...other } = this.props
    const node = ReactDOM.findDOMNode(this)

    if (!enabled(this, node)) {
      return
    }

    if (node !== undefined) {
      const children = nodes(this, node)
      const heights  = this.constructor.getHeights(children, byRow)

      for (let row = 0; row < heights.length; row++) {
        const max = heights[row][heights[row].length-1]

        for (let i = 0; i < (heights[row].length - 1); i++) {
          heights[row][i][0].style[property] = max + 'px'
        }
      }
    }
  }

  render() {
    return (
      <div {...other}>
        {this.props.children}
      </div>
    )
  }


Ingestion: port offers-related endpoints to new ingestion system

We already have a new offers table (and processor updating offers in a database) so should be easy to implement endpoints below:

[x] /offers (#1610)
[x] /offers/{id} (#1602)
[x] /accounts/{account_id}/offers (#1694)
[x] /order_book - I think order book graph can be used, it already has sorted order books inside, if not just use a DB. (#1705)
[x] /paths (already implemented)

Each endpoint should be done as a separate PR.
This work is part of #1577.

This is done cc @tamirms


[radio] update min receive on ahead/after values

See https://github.com/openthread/openthread/pull/9041

LGTM. Thanks Jonathan!

@jwhui


Python 3 support, please

Python 3 support, please

Here it is: https://github.com/alaingilbert/pyogame/commit/e7fac757c276704cf9a7fb8b3645e89ccf950670
please verify :)

Yes!
Thank you~


Bluetooth: Mesh: Persistent Storage: Publication address not restored

Hi all.
In the last couple of days my Team and I are attempting to use the BT-Mesh-Settings API, with our current implementation being based on self-provisioning and self-configuring (We have our reasons). After a bit of grappling, we found out the updated mesh_demo (We've had an offline copy of v1.12) which does exactly what we've been looking after.
However, the problem is it doesn't work for us as expected.
The Node's address, or more specifically, the Primary Element's address (As we don't have any more for now) is not restored upon a power-cycle, leading to error -49:EADDRNOTAVAIL when publishing data using a publication context/model.
Since we're self-provisioning, we could "overcome" this issue by manually calling the bt_mesh_comp_provision function, which from our understanding should assign the address - But it's an ugly solution and wouldn't work for prod-ready provisioning.
Now the question is - Is the address not restored on purpose? It seems rather foolish to restore settings on boot after a system reset of some kind just to wait for the node to be re-provisioned, isn't it?
If it's not, I'm afraid this is some kind of bug, or perhaps, we're using it wrong? @jhedberg

Storing and restoring the range of assigned addresses should work fine, and does work fine using the existing sample apps in the upstream tree. The relevant code is in subsys/bluetooth/host/mesh/settings.c where net_set() is responsible for restoring and store_pending_net() for storing. These deal with the device key and the primary element address (from which the remaining elements, if any, are derived).
I'm a bit confused by what you're doing - you say you're self-provisioning. What exactly do you mean by that? What APIs do you call and in what order?

@MrPointer what value does your bt_mesh_provision() call return?

@MrPointer also, you earlier mentioned bt_mesh_comp_provision() - did you mean bt_mesh_provision() instead? If you're calling the stack-private bt_mesh_comp_provision() function that could explain some of the behavior you're seeing.

@jhedberg No no, I don't call the bt_mesh_comp_provision function, don't worry :laughing:
I mentioned it as a possible solution we've thought of, in case there's indeed a bug.
About the bt_mesh_provision function - On the first run after flashing the board i.e before any settings are persisted, the function exits successfully with error code 0.
On the 2nd run, after power-cycling i.e settings have been already persisted and loaded, it returns with error code EALREADY, which is exactly what we expect.

@MrPointer are you sure your primary element's address is unassigned? There is no place in the mesh code that would return EADDRNOTAVAIL for that situation. That said, the publishing functions will return EADDRNOTAVAIL if you haven't configured a publishing address, or if there's no app key to use for publishing.

@jhedberg Actually I'm not sure about that, however, about the other you mentioned - It might possibly be the problem here, I'll need to do some checks.
Theoritically shouldn't the publication address be stored and restored?
Because I'm preety sure the App Key is persisted... I'm not wrong am I?

@MrPointer yes, both App Keys and Model Publication should be restored if previously set through the configuration model. Is that how you're configuring it? E.g. manually assigning an address to your publication context will not work since then the stack can't know that it needs to store something to flash.

@jhedberg Hmmm... That seems to be it - We're manually assigning the publication address, as part of the self configuration. Isn't there a way to use publication contexts when self-configuring?

@MrPointer yes, by using the configuration client API. I.e. bt_mesh_cfg_mod_pub_set() from include/bluetooth/mesh/cfg_cli.h. The mesh_demo app already uses several configuration client APIs, so I'm surprised you didn't use it for model publication as well.

@jhedberg Sorry for the delay, have been busy with something else.
I think we misunderstood each other - When you said "manually", I thought you meant self-configuring.
That being said, we are using the bt_mesh_cfg_mod_pub_set function to configure the pub context.
Also, I've rerun our tests and the Node's address is indeed restored as expected. Publication address however, is not.

I did some testing with samples/bluetooth/mesh_demo, and I am not able to reproduce this issue - the publication address gets correctly restored after a power cycle. I did however have to increase some buffer counts for samples/bluetooth/mesh_demo to make the Model Pub Set & Model Pub Status messages get sent & processed properly:
CONFIG_BT_MESH_TX_SEG_MSG_COUNT=3
CONFIG_BT_MESH_ADV_BUF_COUNT=14

Also note that the processing of the configuration messages happens through a queue, so won't see it take effect immediately when the bt_mesh_cfg_mod_pub_set() call returns.

One more tip: if you haven't done so already, please enable CONFIG_BT_DEBUG_LOG=y so that you can see any error & warning logs from the stack.

@jhedberg Yes I know that thing about the queue, although it always seems that none of its' element is parsed until the bt_ready functions exits, which is somewhat strange (or not if it's the same thread processing them, this is internal and I hadn't looked at it).
I'm not near the code right now so I can't check the prj.conf, however, I surely remember setting the CONFIG_BT_MESH_TX_SEG_MSG_COUNT to 3, so just the CONFIG_BT_MESH_ADV_BUF_COUNT needs to be validated. Will edit once I'll check.
Lastly, regarding the logging tip - I'm aware of that as well but its' quite inconvenient to do when testing on a completely offline machine, not to mention porting logs outside 😅
I'll try to attach meaningful logs nevertheless.

@MrPointer you can do the configuration client calls blockingly, by passing a non-NULL status parameter (usually the last parameter). That means "I'm interested in the final status, only return once you have received the response". The challenge with this is that the local mesh network interface is processed through the system workqueue, which happens to be the same context that the bt_ready callback gets called in. So you can't do any blocking configuration client calls directed at the local node from the bt_ready callback, since it will just result in a deadlock and a timeout when waiting for the response (the default wait is 2 seconds).

@jhedberg Thanks for the explanation, it makes sense.
On a side note, could this be documented? I haven't seen it anywhere in the documentation nor the API, along with all other configuration methods, which is quite oppressive...

@MrPointer any contributions to the configuration client API documentation are welcome ;)
There are some reasons I haven't gotten around to it yet:

It's huge, and for the most part the API maps 1:1 to what's already documented in the Bluetooth Mesh Profile specification (Section 4).
It's not really useful for anything else than talking to the local node, which is something I consider a hack/demo use case (hence documentation would be good, but it's not as important as the other APIs).

The configuration client API will for the most part work for talking to other nodes, but it fails at the stage of selecting the right Device Key. Currently the stack only knows about its own Device Key that was assigned to it by a provisioner. Knowing other nodes' Device Keys implies being a provisioner ourselves (or having been delegated the task of configuring other nodes by a provisioner) which is something that stack has no support for (yet - I welcome it if someone wants to pick up this task).

@jhedberg This is very reasonable of course, after all my usage is not very standard, and wouldn't be when project will be ready for production.
Had I had the time, I would happily documented it. Maybe someday I will 😉
Back to topic's issue - It seems I won't be able to test anything today and my peers are also away from work. Hopefully tomorrow we'll return with some answers 😃
@RonAmihai Please review this when you have time and return to us with an update.

Our -EADDRNOTAVAIL actually appears inside the bt_mesh_model_publish function, after our custom publication callback (the 'update' field of the publication context structure) is called.
Inside bt_mesh_model_publish, there is a call to bt_mesh_app_key_find, which returns NULL and therefore bt_mesh_model_publish returns -EADDRNOTAVAIL

@jhedberg Just need to mention once again:
Start from the first power-cycle we are not calling the bt_mesh_cfg_mod_pub_set, since there are stored BT settings therefore configuration shouldn't be needed.
The above error appears only after the first power cycle.
The first boot, which calls bt_mesh_cfg_mod_pub_set, works perfectly and the publication callback publishes without issues in this case.

So now we've gone from the local unicast address missing, to the publication (destination) address missing, to there not being an app key? :)
Could someone update the topic of this issue accordingly? (I already did it once)

I'm unable to reproduce the App Key issue. I added some printk calls, without any other modifications, to the upstream mesh_demo, and it shows that AppKey Index 0 is correctly restored to the internal App Key list as well as the vendor model binding.

And for the record, the printk calls I added look like this: http://ix.io/1lNX

@jhedberg We've got some updates which might give more insight into the issue.
We've noticed an internal call to bt_mesh_app_key_find always returns NULL after a power-cycle, i.e On the 2nd run/boot.
When sending a message through a publication context, the error -EADDRNOTAVAIL is returned as a result of an internal call to bt_mesh_app_key_find.
When sending a manual access-layer message (bt_mesh_model_send), the error -EINVAL (-22) is returned as a result of an internal call to bt_mesh_app_key_find.
We're attempting to attach some more logging output now to give even more insight on what's happening.

Log1 (First Boot).txt
Log2 (After Power Cycle).txt
prj.conf.txt
@jhedberg I've attached few logs, alongside our proj conf file.
The first log represents the first boot of the device, without any previous stored BT settings. It continuously publishing data (5s intervals). I've captured only the first publish events.
The second log represents boots after the first power cycle - with previous stored BT settings. The device just fails on the first publishing and hangs in this situation.

Actually, I'm not sure it's valid to rely on the ordering of settings keys, so I've created a pull request to remove this check: #9760
If it fixes the issue for you please comment in the PR so that we can get it merged.


Adding headers using pre-commit

As the title.

I have added the header to the VM files manually.

@klmcadams


Fakeldap in dev env

username<EMAIL_ADDRESS>pass: testing

@shubham-padia is this ready for review/testing?  I wasn't sure because the tests are broken.

Nope, this isn't ready for review yet.

closed in favour of #10181

@shubham-padia why did you need to close this, rather than force-pushing to the branch?


Modal "Que tal tu experiencia": Customer changes

Explication
The client left some comments about the design of the modal "How was your experience?"
Screenshots

Checklist
This issue can be closed when the following tasks are complete:

[ ] Please change the position of the subtitle and title, put the subtitle on the top and the title under the subtitle
[ ] The subtitle is not so separated between
[ ] The subtitle have a more stronger color
[ ] The subtitle is bolder

Check comments, title and subtitle were changed, please tell me
https://www.figma.com/file/tbhMgDT10bbVjB9GazF97y/Dasher?node-id=35%3A57
Experience view

The new modal is very good, I like it a lot

I left a comment regarding the color of the text @angelik0828 please check

ok reviewed and resolved.

check that your tasks have the corresponding labels


Some of the rows has combined UT names:

https://api.rootnet.in/covid19-in/unofficial/covid19india.org/statewise/history
This arises for may data ->   from "day": "2020-05-06", These cases are appeared.
Case1 (combined UT + Daman and Diu separate entity)
   {
            "state": "**Dadra and Nagar Haveli and Daman and Diu**",
            "confirmed": 1,
            "recovered": 0,
            "deaths": 0,
            "active": 1
          },
          {
            "state": "Nagaland",
            "confirmed": 0,
            "recovered": 0,
            "deaths": 0,
            "active": 0
          },
          {
            "state": "**Daman and Diu**",
            "confirmed": 0,
            "recovered": 0,
            "deaths": 0,
            "active": 0
          },

Case2: (combined UT but no Daman and Diu)

As DNH & DD have become a single UT, we have combined them in our api. API that you mentioned is a derived version of the original API. Please do contact the maintainer of the API https://twitter.com/amodm?lang=en if you have further queries.


docs: add documentation index into main README

Description:
Add documentation index into main README
Motivation and Context:
Make it easier for people to find what they need in our documentation.
How Has This Been Tested?
Manually
Types of changes:
Docs update
Checklist:

[x] My code follows the code style of this project.
[x] I have reviewed and updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes where needed.
[x] All new and existing tests passed.
[x] My commits have been squashed into a concise set of changes.

Coverage remained the same at 20.069% when pulling 551d227a9034021b8e85d0ffc775c75315cd6fe6 on mrfelton:docs/index into b86226e5258c4f76ef27540db663e21eb458589a on LN-Zap:master.


List all submissions for an assignment from a particular student API change

For redundancy we may want to add "student_id" here:
https://github.com/lxylxy123456/ngshare/blob/master/api-specifications.md#response-4

What is/are the benefits and can we make it optional to implement?

If you call the wrong API (/api/submissions/<course_id>/<assignment_id>) you will catch it by placing an assert on checking student_id. Also it makes the two APIs look the same (which may probably save some code in the backend)

You can also assert that student_id doesn't exist. I will add it as an optional field.

I think asserting student_id does not exist does not make sense. You should either make it a required field (it is just one line change in backend), or we can wait for other group members to discuss.

We are talking about testing the server/client. I see no point in forcing implementations to have the student_id simply for testing purposes. I suppose it can be useful for hiding other student's submissions in case of a terrible coding mistake, but I think that should not be a responsibility of the API.

What do you mean by testing?
I believe the API should make it clear about what will be returned. If you want to have this checking feature, you need to either:

Say in API that student_id will be returned, client will check value of student_id
Say in API that student_id must not be returned, and client will assert student_id doesn't exist
Or if you say in API it is an optional value (server decides whether to return it), then the client cannot check anything.

By testing, I mean making sure the client code issues the correct request and the server code sends the correct submissions.
If the field is optional, the client can still do a two part check by seeing if the field exists, and if it does, check the value.

I see. You can make it optional in API and I will make vserver return the student_id value. We can ask Abigail and Kevin about this change on Wednesday.


Leave the screen visible at the bottom

Hello! Thanks a lot for a great library!
I have a question about navigation. I want to make a swipe-back gesture, but there in backstack could be visible only one composable. How can I achieve it?

Hi @TemMax
I don't fully understand the question, but I feel like this is probably not the place for it. This library is a wrapper to official library compose navigation, so you're best bet is to search around how to do what you want (or ask on kotlin slack / stackoverflow) and then you should be capable of doing that same thing in compose destinations.
If you have an issue there, do let me know at that point!
Closing it, but let me know how it goes!


Allow option to set HTML5 "preservePitch" code boolean to FALSE

HTML5 has set preserve pitch, otherwise known as time-stretch to keep the pitch of all notes nearly identical to original speed, but in doing so for slower speeds, causes horrible sound quality, not worth listening to.
I am providing a link to Mozilla developers page so you can see how to change this option, in HTML code, as well as Javascript
https://developer.mozilla.org/en-US/docs/web/api/htmlMediaElement/preservesPitch
This allows the pitch to go down with slower speeds, just like slowing down a 45 rpm record to 33, with ZERO additional sound processing and near identical audio quality.

Awesome finding!


Latitude e6440 support

It is possible to add support to Latitude e6440? I can not find any drivers and i would like to have it. I'm using Ubuntu 21

What do you want to do?
Have you installed PCSC?
Does PCSC detect your reader?
What ControlVault device does lsusb show?
Have you checked https://blog.g3rt.nl/enable-dell-nfc-contactless-reader.html mentioned in README?

Closing due to inactivity. Please feel free to reopen this ticket.


VS v140 narrowing conversion

First, thanks for this awesome logging library. This is exactly what I needed. Although it required some manual patching to get the deprecation warnings and ISO C stuff sorted out. (http://pastebin.com/gRSSeuvv), since this is not about the deprecation warnings I left them out and just pastebinned them.
The real "issue" is this error:

error C2398: Element '3': conversion from 'long' to 'unsigned int' requires a narrowing conversion

which originates from here:
#define VLOG_SCOPE_F(verbosity, ...)                                                               \
	loguru::LogScopeRAII LOGURU_ANONYMOUS_VARIABLE(error_context_RAII_) =                          \
	((verbosity) > loguru::current_verbosity_cutoff()) ? loguru::LogScopeRAII() :                  \
	loguru::LogScopeRAII{verbosity, __FILE__, __LINE__, __VA_ARGS__}

Adding a C Style cast to __LINE__ fixes the problem though.
#define VLOG_SCOPE_F(verbosity, ...)                                                               \
	loguru::LogScopeRAII LOGURU_ANONYMOUS_VARIABLE(error_context_RAII_) =                          \
	((verbosity) > loguru::current_verbosity_cutoff()) ? loguru::LogScopeRAII() :                  \
	loguru::LogScopeRAII{verbosity, __FILE__, (unsigned int)__LINE__, __VA_ARGS__}

Should be fixed in 4886bbe2f4bb58225c813d59789a2818dc6124eb. Thanks for your contribution!


Notebook 3 R vst function takes extremely long time to run

%%R
vst_out=vst( as.matrix(rawMatrix), #data matrix
            cell_attr=cell_df, #dataframe containing batch variable
            n_genes=3000, #most variable genes in your data
            batch_var='data.batch', #name of the batch variable
            method='qpoisson', #type of statistical model. use "poisson" for more precision but much slower execution
            show_progress=TRUE, #show progress bars
            return_corrected_umi=TRUE) #return corrected umi count matrix

This cell runs indefinetely. There is no error in the kernel, only something related to sparkmonitor (no module named sparkmonitor)

Turns out to be something related with uCloud. Restarting the kernel fixed the issue. Still, R magic cells are slower to run somehow.


[Improvement][workFlow] online,offline and delete Button, edge Popconfirm message does not take effect

Search before asking

[X] I had searched in the issues and found no similar feature requirement.

Description
online,offline and delete Button, edge Popconfirm message does not take effect

Are you willing to submit a PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

The button is inside.
https://www.naiveui.com/en-US/os-theme/components/popconfirm


Different Behavior for + and - with PMVector

The following snippet works,
| vect test |
vect := #(1 2 10) asPMVector .
test := vect + (-1 * vect max)

whereas,
| vect test |
vect := #(1 2 10) asPMVector .
test := vect - vect max

does not.

PMVector>>+ implementation is very different from PMVector>>-.
I don't know why.

Exactly, PMVector>>+ and PMVector>>* have a similar implementation but PMVector>>- is implemented differently.
Yes, I'll add tests for these.

Apparently this works:
- aVectorOrNumber
	"Answers the difference of the receiver with aVector."

	^ aVectorOrNumber negated addWithVector: self

Yes add tests with difference with numbers and vectors.

Tests written and gave a suggested fix for the issue. PR submitted for review.


Implement telemetry

part of https://github.com/nitrictech/nitric/issues/329

Codecov Report
Base: 60.56% // Head: 59.50% // Decreases project coverage by -1.05% :warning:

Coverage data is based on head (bf910ca) compared to base (4f72a2f).
Patch coverage: 39.42% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop     #342      +/-   ##
===========================================
- Coverage    60.56%   59.50%   -1.06%
===========================================
  Files           43       46       +3
  Lines         4455     4633     +178
===========================================
+ Hits          2698     2757      +59
- Misses        1572     1686     +114
- Partials       185      190       +5

Flag
Coverage Δ

unittests
59.50% <39.42%> (-1.06%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/membrane/defaults.go
0.00% <0.00%> (ø)

pkg/worker/instrumented_pool.go
0.00% <0.00%> (ø)

pkg/worker/instrumented_worker.go
0.00% <0.00%> (ø)

pkg/membrane/membrane.go
68.07% <34.09%> (-8.97%)
:arrow_down:

pkg/plugins/gateway/lambda/trace.go
36.36% <36.36%> (ø)

pkg/plugins/gateway/lambda/lambda.go
61.27% <78.57%> (+1.17%)
:arrow_up:

pkg/adapters/grpc/secret_grpc.go
87.80% <85.18%> (-1.29%)
:arrow_down:

pkg/adapters/grpc/queue_grpc.go
60.90% <85.71%> (+2.91%)
:arrow_up:

pkg/adapters/grpc/event_grpc.go
42.30% <86.66%> (+10.56%)
:arrow_up:

... and 1 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

Update on this one, after discussion with @asalkeld looking at native gRPC telemetry to allow us to use native headers (at least in the case on unary calls, for preserving trace information.)


Feedback for features

I'd like to get an idea of what commands are most desired by the community so I know what to prioritize implementing. Some are really obvious:

[ ] list watchlists
[ ] list option chain for a symbol at a given date (potentially defaulting to the closest monthly to 45 days)
[ ] place options orders
[ ] place futures orders
[ ] place stock orders
[ ] list portfolio
[ ] list order history
[ ] cancel/replace orders
[ ] list activity
[ ] list positions
[ ] portfolio statistics (net liq, beta-weighted delta, etc.)
[ ] compile past and present data of portfolio for analysis
[ ] portfolio risk analysis (correlation, % of capital used relative to VIX, etc.)

I'm sure I'm missing lots of things, so I'd appreciate feedback on what other features people would like.

this one might be a bit harder to implement and we might not be able to do anything on it before the release.
I've written some code that allows me to create custom price alerts. I'm using IB for a minute-by-minute data subscription and Telegram to send out alerts. I have simple code that alerts when prices of an underlying surge and when crossing a rolling window, and these are configurable with a sort of "heat level" setting i.e. 100 normal amount of alerts, 200 is a lot of alerts (for things that I want to watch closely) and 50 would be something that I only want to be alerted if there is a very large move. can also do above/below threshold levels, of course.
I just don't think we know what the functionality of the API will allow at this point in time.

should and/or could the tastypl project be fully integrated here?
would be convenient if you could run commands like
tastyworks-cli tastypl -input yourcsvfile.csv -printpl -positions -chart

...corresponding to go run tastypl.go -input yourcsvfile.csv -printpl -positions -chart, although with the api likely wouldn't have to export the transactions file.

would be nice to be able to archive and resubmit futures orders, for some reason the platform currently doesn't allow gtc futures orders, which means that I have to manually enter orders before the overnight session. they say they're working on a fix but I guess it's complicated.
if have the feature that sends futures orders, then being able to archive orders and resubmit efficiently would be useful.

scanning functionality could be a whole project itself.
one scanning function that comes to mind would be: for a given chain, try all (or a large number of) possible combinations of iron condors and return possible choices ranked by "expected edge", i.e. the difference between pop and breakeven probability given by the width of the strikes and the premium collected.

should and/or could the tastypl project be fully integrated here?
would be convenient if you could run commands like
tastyworks-cli tastypl -input yourcsvfile.csv -printpl -positions -chart

...corresponding to go run tastypl.go -input yourcsvfile.csv -printpl -positions -chart, although with the api likely wouldn't have to export the transactions file.

That's a good idea. Definitely a useful feature as long as TW doesn't provide portfolio charts itself.

scanning functionality could be a whole project itself.
one scanning function that comes to mind would be: for a given chain, try all (or a large number of) possible combinations of iron condors and return possible choices ranked by "expected edge", i.e. the difference between pop and breakeven probability given by the width of the strikes and the premium collected.

this one might be a bit harder to implement and we might not be able to do anything on it before the release.
I've written some code that allows me to create custom price alerts. I'm using IB for a minute-by-minute data subscription and Telegram to send out alerts. I have simple code that alerts when prices of an underlying surge and when crossing a rolling window, and these are configurable with a sort of "heat level" setting i.e. 100 normal amount of alerts, 200 is a lot of alerts (for things that I want to watch closely) and 50 would be something that I only want to be alerted if there is a very large move. can also do above/below threshold levels, of course.
I just don't think we know what the functionality of the API will allow at this point in time.

I think these ideas could be done. However it might be better to have them as plugins or something, and keep the "core" functionality here.


Release 0.1.4 to NPM

The latest version is 0.1.2

Sure. I missed this - will update them (npm, bower) to 0.1.5.

👍

Closed by #18.


734 document v1 paths should be urlencoded

I confirm that this contribution is made under the terms of the license found in the root directory of this repository's source tree and that I have the authority necessary to make this contribution on behalf of its copyright owner.
Closing #734.
Made the function that creates the path do quoting and changed unit test accordingly.

This might be a problem for some existing users, but I think we should just mention it in the release notes, as it is the right thing to do