├── .github └── stale.yml └── README.md /.github/stale.yml: -------------------------------------------------------------------------------- 1 | # Number of days of inactivity before an issue becomes stale 2 | daysUntilStale: 90 3 | # Number of days of inactivity before a stale issue is closed 4 | daysUntilClose: 21 5 | # Issues with these labels will never be considered stale 6 | exemptLabels: 7 | - pinned 8 | - security 9 | # Label to use when marking an issue as stale 10 | staleLabel: wontfix 11 | # Comment to post when marking an issue as stale. Set to `false` to disable 12 | markComment: > 13 | This issue has been automatically marked as stale because it has not had 14 | recent activity. It will be closed if no further activity occurs. Thank you 15 | for your contributions. 16 | # Comment to post when closing a stale issue. Set to `false` to disable 17 | closeComment: false 18 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Code of Conduct 2 | 3 | The purpose of the Functional Programing Slack team is to discuss - you guessed it - functional programming. The goal of this Code of Conduct is to ensure that this purpose continues to be served and that members understand, in broad terms, behavior that is unacceptable in any of the channels on the team. 4 | 5 | It is impossible to legislate perfection so this CoC is not designed to outline every bannable offense or lay out, in specificity, an exhaustive list of what is and isn't allowed. The goal is much more modest: to make sure that members understand the spirit they should uphold and to avoid any surprises in the unfortunate circumstance that someone gets removed from the channel for violating that spirit. 6 | 7 | To date, the vast majority of participants have fostered an incredible atmosphere of collaboration, with members offering advice, feedback, etc and we expect that will continue. There have been rare occurrences of flagrant or derogatory language being directed at other members. There have been threats of violence. This behavior has no place on the team. 8 | 9 | Clear-cut and egregious violations may result in immediate removal from the team without warning. If there's an isolated incident followed by a quick resolution or apology to the point where it's clear to any sane, objective third-party that the offending members' continued presence on the team presents no substantial impediment to continued productive discussion focused on FP, we hope a warning will suffice and we can all move on. 10 | 11 | What _precisely_ qualifies as "resolution" or "apology"? We do not attempt to precisely define those terms because this CoC is not intended to be a sprawling regulatory framework which would require lawyers to interpret prior to enforcement. Instead, we've placed significant trust in the few admins and other long-standing key members to assess situations on a case-by-case basis. 12 | 13 | In a word, if you are removed from the team, it means you blatantly violated very basic, very reasonable expectations of good behavior and you're kidding yourself if you think otherwise. 14 | 15 | Some _examples_ (but NOT an exhaustive list of bad behavior): 16 | 17 | - promotion of racism or use of racist language 18 | - promotion of sexism or use of sexist language 19 | - promotion of homophobia or use of homophobic language 20 | - promotion of transphobia or use of transphobic language 21 | - any other derogation of a person on the basis of their identity of any kind 22 | - "fuck you" directed at someone (not said in jest) 23 | - "I'm going to kill you" (not said in jest) or any other threats of violence 24 | - monopolizing channels with personal conflicts to the point where it dominates the conversations and affects the ability of members to focus on the channel topic 25 | 26 | All but the last of these apply to communications via Direct Messages as well, not just channels. 27 | 28 | None of the admins want to be dealing with enforcement of this CoC or policing activity in the channels. It's annoying and the majority of the members are here to engage in productive conversation. Isolated incidences rarely end up being the issue. Banning typically occurs when we hear several reports about a member engaging in a pattern of behavior which detracts from the welcoming environment that has been in place since inception. 29 | 30 | If you have questions, please contact any of the admins: @levinotik @dk @dridus @rickasaurus @fixplz 31 | 32 | # Request an Invite 33 | To request an invite to the Functional Programming community on Slack, please visit [fpslack.com](https://fpslack.com) 34 | 35 | 36 | # Jobs channel 37 | 38 | [Note: these rules and their motivations have been discussed ad nauseam in the channel. Please don’t start a debate about it again in the channel. Doing so may result in a ban from the channel. We are happy to debate this and any other issues privately.] 39 | 40 | 1. Job postings must clearly be strictly related to Functional Programming 41 | 1. Does the job involve working mostly with any of Haskell/GHCJS/PureScript/Elm/OCaml/ReasonML/F#? If "yes", you can post the job. 42 | 2. Does the job involve working mostly with Scala AND the "cats" or “scalaz” libraries? If "yes", you can post the job. 43 | 3. Otherwise, the job doesn't belong in this channel, so please don't post it. 44 | 2. Job postings must include a description, including at least the following information: 45 | 1. A general description of the position. 46 | 2. Required skills and experience. 47 | 3. Working conditions: Location, Remote OK?, part-time/full-time 48 | 4. A technical description of the position, demonstrating its relevance to the channel. Include details such as: programming languages, tools and frameworks used 49 | 5. Any additional information you feel may be helpful and/or relevant. 50 | 3. Do **NOT** post misleading information 51 | - For example: including the keyword “Haskell” in the posting, when the job itself does not involve writing Haskell code. 52 | 4. The position must be an actual job opening being actively hired for. "Interview" processes or labor sourcing platforms that require spec work / free labor for an opportunity to be considered for the position are unacceptable. Small, useless work samples given after initial screening are fine. 53 | 54 | ### Important 55 | 56 | It has been our experience that companies and recruiters will describe a job as "FP" while the actual, day-to-day job ends up having very little to do with FP. This is a bait-and-switch that engineers are unfortunately familiar with. Therefore, __unless the primary language used in the job is a pure functional programming language, such as Haskell, it is not sufficient for a job posting to simply state that the job is "FP" or that the company uses "FP techniques".__ 57 | 58 | As an example, use of the Scala programming language does not in itself satisfy the requirements for the jobs channel because it is a "multi-paradigm" language and does not enforce use of FP -- the language can be used as anything from a nicer Java to a Haskell-wanna-be -- so if you want to post a Scala role in the jobs channel, it must include specific details which demonstrate that paradigm being used in practice is FP (e.g. extensive use of scalaz, cats, etc). 59 | 60 | #### Note 61 | 62 | Jobs can also be submitted as a Github issue here https://github.com/Functional-Programming-Slack/community/issues with the appropriate labels. 63 | --------------------------------------------------------------------------------