├── README.md ├── event_organizers.md ├── governance └── membership.md ├── summit-us-2016 └── governance-panel-notes.md ├── sustainability_program.md └── twitter.md /README.md: -------------------------------------------------------------------------------- 1 | ## Archived 2 | 3 | * Governance is now in the [governance repo](https://github.com/typelevel/governance) (public). 4 | * Maintainers can communicate internally via the [team discussion](https://github.com/orgs/typelevel/teams/maintainers). 5 | * Documentation tickets belong on [the website](https://github.com/typelevel/typelevel.github.com). 6 | * Moderation requests follow the [code of conduct](https://github.com/typelevel/.github/blob/main/CODE_OF_CONDUCT.md#moderation). 7 | -------------------------------------------------------------------------------- /event_organizers.md: -------------------------------------------------------------------------------- 1 | ## CH - Switzerland 2 | * Zürich: Mario Pastorelli ([@melrief](https://github.com/melrief)) 3 | 4 | ## DE - Germany 5 | * Augsburg, Munich: Frank S. Thomas ([@fthomas](https://github.com/fthomas)) 6 | * Munich: Nepomuk Seiler ([@muuki88](https://github.com/muuki88)) 7 | * Munich: Sebastian Wiesner ([@lunaryorn](https://github.com/lunaryorn)) 8 | 9 | ## GB - United Kingdom 10 | * London: Kingsley Davies ([@kings13y](https://github.com/kings13y)) 11 | * Brighton/London: Miles Sabin ([@milessabin](https://github.com/milessabin)) 12 | * London: Noel Markham ([@noelmarkham](https://github.com/noelmarkham)) 13 | * London: Yilin Wei ([@yilinwei](https://github.com/yilinwei)) 14 | * London: Zainab Ali ([@zainab-ali](https://github.com/zainab-ali)) 15 | 16 | ## IT - Italy 17 | * Milano: Gabriele Petronella ([@gabro](https://github.com/gabro)) 18 | 19 | ## PL - Poland 20 | * Pawel Szulc ([@rabbitonweb](https://github.com/rabbitonweb)) 21 | * Marcin Matuszak ([@mrcmatuszak](github.com/mrcmatuszak)) - TL Summit as a part of Scalapolis.pl conference 22 | 23 | ## US - United States 24 | * NY, New York: Kailuo Wang ([@kailuowang](https://github.com/kailuowang)) 25 | * NY, New York: Miguel Iglesias ([@caente](https://github.com/caente)) 26 | * OR, Portland: Rob Norris ([@tpolecat](https://github.com/tpolecat)) 27 | * OR, Portland: Shane Delmore ([@ShaneDelmore](https://github.com/ShaneDelmore)) 28 | * PA, Philadelphia: Stephen Carman ([@hntd187](https://github.com/hntd187)) 29 | -------------------------------------------------------------------------------- /governance/membership.md: -------------------------------------------------------------------------------- 1 | ## Typelevel membership criteria and process 2 | 3 | Typelevel has two levels of project membership: projects can have an "incubator member" status or a "full member" 4 | status. 5 | 6 | ### Incubator membership 7 | 8 | The intention is that the criteria for incubator status be quite lax, and a strong emphasis is placed on 9 | the collective responsibility of Typelevel members for helping new incubatees move to full membership status. 10 | 11 | 1. There must be a consensus amongst the project's stakeholders that they want to join Typelevel. 12 | 2. The project must be willing to support the Typelevel code of conduct or something equivalent. 13 | 3. The project should be aiming to promote pure, typeful, idiomatic functional programming in Scala. 14 | 4. If the primary output of the project is software artefacts then it should aim to complement them with accessible, 15 | idiomatic documentation. 16 | 17 | The process for joining is as follows, 18 | 19 | 1. An issue must be created in this issue tracker proposing Typelevel membership for the project. 20 | 2. Criteria (1) and (2) should be verified. 21 | 3. Suitability of the project for joining Typelevel, and the suitability of Typelevel membership for the project, 22 | should be discussed constructively. 23 | 4. If there are no unaddressed objections to the projects joining Typelevel after a period of one week, then it will 24 | move into the incubator stage. 25 | 26 | Note that, 27 | 28 | + The project does not need to be nominated by an existing Typelevel member. 29 | + At the time of joining, the project does not have to fully exemplify pure, typeful, idiomatic functional 30 | programming. There is, however an expectation that it will aim to move in that direction during an incubation period. 31 | Typelevel members are expected to encourage and help with that development. 32 | 33 | ### Full membership 34 | 35 | In addition to the incubator criteria full member projects must satisfiy the following additional criteria, 36 | 37 | * The project should exemplify pure, typeful, idiomatic functional programming. It should not be deeply rooted in 38 | things such as side-effects and mutation - put differently, it should be fairly easy for those working in pure 39 | functional code bases to bring in your library. Mutation and other side-effecting properties is not 40 | strictly forbidden, but should have a good documented reason for doing so (e.g. performance, limitation of the 41 | language, etc.). 42 | * Documentation for the code should (a) exist (b) be machine checked so as to enforce all documentation is up to date. 43 | * There must be at least one active maintainer of the project who will field pull requests, issues, questions, etc. 44 | * There much be some versioning scheme that communicate binary and/or source compatibility. 45 | 46 | The process for full membership is as follows, 47 | 48 | 1. An issue must be created in this issue tracker proposing full membership for the project. 49 | 2. The criteria listed above should be verified. 50 | 3. Suitability of the project for becoming a full member should be discussed constructively. 51 | 4. If there are no unaddressed objections to the projects full membership after a period of one week, then it will 52 | become a full member. 53 | 54 | Note that, 55 | 56 | + Full membership status implies a degree of endorsement of the project by the other full members of Typelevel. 57 | + The criteria listed above should be actively maintained and if they cease to hold and that isn't rectified within a 58 | reasonable period then the project's membership might revert to incubator status or be revoked. 59 | -------------------------------------------------------------------------------- /summit-us-2016/governance-panel-notes.md: -------------------------------------------------------------------------------- 1 | Dave Gurnell's notes from the Governance Session at the Typelevel US Summit: 2 | 3 | # Agenda 4 | 5 | - Discussion about Typelevel's aims and purposes, decision making process, and general constitution 6 | - Should there be a non-profit Typelevel coorporate entity? 7 | - What are Typelevel's aims and purposes? 8 | - How should we reach out to the wider Scala community? 9 | - How can we be more diverse? 10 | - Can/should Typelevel have a "group voice"? 11 | 12 | # Discussion about Typelevel's aims and purposes, decision making process, and general constitution 13 | 14 | Erik: 15 | 16 | - We should be supporting the community who want to do principled FP in Scala. 17 | - Lots of aspects: better documentation, support, codes of conduct, etc. 18 | - Not making the best the enemy of the good... do everything in proportion to its importance. 19 | - About incubator projects: 20 | - permissiveness is good 21 | - it's more important to let people in whose goals are aligned with Typelevel than having arguments about minutiae 22 | - avoid legal-style arguments about functional purity etc 23 | 24 | Miles: 25 | 26 | - One of Typelevel's goals should be to share ideas and code 27 | - We should aim to depend on each others' projects 28 | - Strive towards some sense of binary compatibility 29 | - Need learning resources that are going to work for people 30 | 31 | Miles: 32 | 33 | - We need transparency to ensure we're representing peoples' opinions 34 | 35 | Lars: 36 | 37 | - We need processes in place for governance to make things transparent 38 | 39 | Erik: 40 | 41 | - If everyone here is in agreement about the main goals of Typelevel, 42 | we can more onto governance. 43 | 44 | Chris Hodapp: 45 | 46 | - We're lacking some types of documentation 47 | - "Idiomatic and accessible learning resources and documentation" 48 | should encompass more than the docs we have 49 | - "Accessible" should include putting stuff in easy-to-find locations 50 | 51 | Person A (forgot their name -- apologies): 52 | 53 | - Do we have requirements for licenses? 54 | 55 | Lars: 56 | 57 | - No. Not currently, although all libaries share a set of core licenses 58 | 59 | Michael Pilquist: 60 | 61 | - The first goal ("pure, typeful, functional programming in Scala") 62 | can be interpreted too strongly 63 | 64 | Erik: 65 | 66 | - Yes. I write a lot of impure code. 67 | - We should qualify it so it's received in the right light. 68 | (TODO: Catch up with Erik about his precise phrasing... I missed it) 69 | 70 | Lars: 71 | 72 | - Stew: can you inform us how Debian works? 73 | 74 | Stew: 75 | 76 | - Debian operates completely in the open 77 | - There is a dictator at the top in an elected position 78 | - The top person delegates to autonomous committees 79 | - The committees run things unless they're overridden by a 80 | heavyweight vote process (with GPG signing and so on) 81 | - Votes are avoided unless really necessary because they're so heavy 82 | 83 | - We've generally been pretty good about design. 84 | - With Cats we've always invited people... anyone... 85 | to come with comments/requirements 86 | - The only time we've taken a wrong turn is where 87 | we've tried to do things behind closed doors 88 | - My main recommendation is that we 89 | publicise decisions widely and encourage feedback 90 | 91 | Miles: 92 | 93 | - That works well for code (an optimistic strategy, 94 | adding features to code and asking for feedback later) 95 | - The problem with that approach for many non-technical decisions 96 | (e.g. negotiations with Lightbend / EPFL) 97 | is that some things have to be decided behind closed doors 98 | 99 | Erik: 100 | 101 | - Sounds like we're moving into the corporate voice agenda point here... 102 | let's step back for a minute 103 | - Do people think we should in general make decisions with small teams, 104 | and only bring voting in when we need to? 105 | 106 | Chris: 107 | 108 | - It's possible to not have an official process for this kind of thing, 109 | but let that process form fluidly around specific problems. 110 | 111 | Lars: 112 | 113 | - A process I've used in the past involves time-limited discussion. 114 | Allow comments for two weeks, and then lock the thread and 115 | see if we can find consensus. 116 | - Should we give project maintainers votes on Typelevel policy decisions? 117 | 118 | Erik: 119 | 120 | - We should open it wider than that. 121 | Anyone who has contributed to any project can have a vote. 122 | - But we should have a rough consensus model in which we don't 123 | need to wait for everyone to vote to resolve an issue. 124 | 125 | Stew: 126 | 127 | - Agreed. We should set a very low bar -- involve more people. 128 | How about including people who have made SO posts about projects, 129 | i.e. people helping in that way as well as actually writing code? 130 | 131 | (There's a general consensus here that we should involve anyone 132 | who is involved in some way.) 133 | 134 | Miles: 135 | 136 | - Ok - do we have enough here to form a process around this? 137 | 138 | Chris Hodapp: 139 | 140 | - We need to make this decision subject to the same decision making process. 141 | We need to ask the mailing list for comments on this decision. 142 | 143 | Miles: 144 | 145 | - Ok. Can someone raise an issue for this? 146 | 147 | Dave Gurnell: 148 | 149 | - We need a defined communication channel for governance proposals and decisions. 150 | - Something persistent. Gitter is too transient. 151 | 152 | Lars/Erik: 153 | 154 | - Let's use Github issues/PRs against github/typelevel/general for decisions, 155 | and Gitter for discussion 156 | 157 | Rob: 158 | 159 | - We should kill the mailing list. No-one uses it any more. 160 | - Can we raise a PR on the typelevel/general github to this effect? 161 | 162 | Lars: 163 | 164 | - I'll do that now. 165 | 166 | Jon: 167 | 168 | - Where do we use Gitter and where do we use Slack? 169 | 170 | Miles: 171 | 172 | - Slack is just for organising the Summits. 173 | - For the Summits we needed to have private conversations about, 174 | e.g., programme selection. 175 | - Nearly all other discussion should be on Gitter. 176 | 177 | 178 | 179 | # Can/should Typelevel have a "group voice"? 180 | 181 | Erik: 182 | 183 | - What should the process be if people want to run a Summit? 184 | 185 | Person B (forgot their name -- apologies): 186 | 187 | - They should propose it, Typelevel should agree to it, 188 | and then they should be fairly autonomous. 189 | 190 | Cody: 191 | 192 | - What would the process be if there was a CoC violation? 193 | We can't have that conversation in the open. 194 | - We need trusted individuals who people can go to. 195 | - There are examples like: CoC violations at Summits, 196 | CoC violations on mailing lists, etc 197 | 198 | Miles: 199 | 200 | - A larger issue is... what if there's a larger problem 201 | with a Typelevel library, and we have to talk to the maintainers 202 | about the library's ongoing involvement with Typelevel? 203 | 204 | Erik/Stew: 205 | 206 | - Should we have an elected representative board? 207 | - People without much power, 208 | but authorised to act on behalf of Typelevel 209 | and consult the community if the situation demands it? 210 | - A group that people can go to to report violations, 211 | who are trusted to deal with things fairly. 212 | - Board members will have to maintain confidentiality 213 | at the discretion of the persion reporting a CoC violation. 214 | 215 | Cody: 216 | 217 | - We already have that on the web site: 218 | Miles, Erik, Stew, and Cody are all named contacts. 219 | 220 | 221 | 222 | # Should there be a non-profit Typelevel coorporate entity? 223 | 224 | Miles: 225 | 226 | - One main motivation for this is in organising Summits, 227 | where we need a bank account to run funds through. 228 | - Should we set up an entity for this kind of thing? 229 | How do we pick what to do, how does it work? 230 | 231 | Jon: 232 | 233 | - Typically, in a charity situation, you'd have govenors. 234 | These aren't necessarily the same people running the organisation. 235 | 236 | Miles: 237 | 238 | - We're not talking about a charity, though. 239 | We're talking about a not-for-profit. 240 | 241 | Stew: 242 | 243 | - With Debian, there are Debian special interest groups that run in each country. 244 | - Those companies run local events. 245 | - There's also a company in the US called SPI who run events like the Summits. 246 | 247 | (We're out of time here. We agree to continue this discussion on github/typelevel/general.) 248 | -------------------------------------------------------------------------------- /sustainability_program.md: -------------------------------------------------------------------------------- 1 | The ultimate goal for this program is to provide ways for the user community to ensure 2 | the long-term sustainability of the development and maintenance of some Typelevel libraries. 3 | 4 | Based on the [Cats ecosystem community survey 2018 results](https://typelevel.org/blog/2019/01/30/cats-ecosystem-community-survey-results.html), as well as feedback from potential donors, we adopted the following principles for the program: 5 | 6 | ### Principles: 7 | 8 | * Paid maintainers focus on supporting the community contributors. In another sentence, 9 | paid maintainers’ first task is to maintain the community-driven development. 10 | More detailed responsibilities are listed below. 11 | * Main obligations to sponsors (individual or corporate) are limited to 12 | - The existing license remains unchanged. 13 | - Timely security patches and mission critical bug fixes. 14 | - Financial contributions will NOT grant contributors extra influence over the development. 15 | - Financial contributors can influence how their contribution is distributed among projects. 16 | * The program is governed by an independent committee. 17 | * As part of our community, sponsors hold values compatible with the [Scala Code of Conduct](https://www.scala-lang.org/conduct/). 18 | 19 | ## Responsibilities for paid maintainers 20 | Based on these principles, we established the following three main goals and relevant tasks for paid maintainers. 21 | 22 | ### Goal 1: Provide guidance for community contributors 23 | 24 | Relevant tasks: 25 | 26 | * Create/maintain contribution guidance documentation 27 | * Review PRs in a timely fashion 28 | * Create friendly issues for first-time contributors 29 | * Provide real-time tech support for contribution related topics 30 | 31 | ### Goal 2: Relieve community contributors from most fastidious, ingrate tasks 32 | 33 | Relevant tasks: 34 | 35 | * Maintain/improve infrastructure, e.g. build, tests, linting etc. 36 | * Plan and manage releases 37 | * Backports to support of old Scala version 38 | * Create documentation 39 | 40 | ### Goal 3: Ensure the ecosystem is unblocked 41 | 42 | Relevant Tasks: 43 | 44 | * Fix mission-critical bug 45 | * Address security vulnerabilities 46 | * Enforce compatibility guarantees 47 | * Take on initiatives that require a significant amount of effort usually too large for casual contributors to 48 | take on, e.g. complete Scala 2.13 migration; merging in typelevel/algebra; integration with Scala 3.0 std library, etc. 49 | 50 | ## Funding source 51 | 52 | We'll be relying on donations from corporation and individual users of the OSS libraries. Aside from monetary assistance, companies can support us by: 53 | 54 | * Providing computing resources/tools such as CI systems, communication platforms, development tools, etc. 55 | * Paid employees' time for code contributions 56 | * Sponsor events such as free training, conferences, by providing the venue, food, etc. 57 | * Donation of training/support services or coupons that we can then exchange for monetary contributions. 58 | 59 | Perks for sponsoring companies include 60 | 61 | * Branding on our sponsors' list (at $200 per month or 100 paid employee hours per year) 62 | * Job posts (at $500/month level) 63 | * Training / Technical support (if we receive such donations) 64 | 65 | We reserve the right to respectfully decline sponsorship offers. 66 | 67 | 68 | ## Typelevel libraries in the program 69 | 70 | 71 | 1. Cats and its external modules projects including 72 | * cats-effect 73 | * cats-mtl 74 | * mouse 75 | * kittens 76 | * cats-tagless 77 | * Cats-collections 78 | 2. Shapeless 79 | 3. Spire 80 | 81 | We are in the process of enlisting more Typelevel libraries into the program based on their maintainers’ as well as sponsors’ interests. 82 | 83 | Please don't hesitate to reach out with questions. Our contact Email is sponsor-contact@typelevel.org 84 | 85 | Thank you for reading this and considering supporting us. 86 | 87 | OpenCollective 88 | -------------------------------------------------------------------------------- /twitter.md: -------------------------------------------------------------------------------- 1 | Twitter access 2 | ============== 3 | 4 | The following people have full access to the Twitter account: 5 | 6 | * [Erik Osheim](https://twitter.com/d6) 7 | * [Tom Switzer](https://twitter.com/tixxit) 8 | * [Miles Sabin](https://twitter.com/milessabin) 9 | * [Lars Hupel](https://twitter.com/larsr_h) 10 | 11 | The following people have tweeting access to the Twitter account: 12 | 13 | * [Kailuo Wang](https://twitter.com/kailuowang) 14 | --------------------------------------------------------------------------------