You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+7-1Lines changed: 7 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -25,12 +25,18 @@ To build the project:
25
25
stack build
26
26
```
27
27
28
-
Once the project has built (which can take a while due to the dependencies for Hakyll), to generate the site use:
28
+
Once the project has built (which can take a while due to the dependencies for Hakyll), generate the site with:
29
29
30
30
```bash
31
31
stack exec -- site build
32
32
```
33
33
34
+
and for development use:
35
+
36
+
```bash
37
+
stack run -- site watch
38
+
```
39
+
34
40
The site will be build in the `_site` directory, and you can open the files in your browser of choice. Due to a Hakyll issue, some sponsor logos will not show up correctly. This is expected behavior, and should be fine for the deployed site.
35
41
36
42
For further information, please refer to the [CONTRIBUTING.md](CONTRIBUTING.md) at the root of this project.
Affiliation means that the group supports the goals of the Haskell Foundation, and, in return, the Haskell Foundation supports this group.
18
-
</div>
19
-
<div>
20
-
Different groups work in different ways, and it would be counter-productive to impose complete uniformity. However, we expect the groups that want to affiliate with the Haskell Foundation to follow a few ground rules, laid out below.
21
-
</div>
22
-
</div>
23
-
<divclass="space-y-8">
24
-
<div>
25
-
Affiliation does not mean that the HF is taking over control of that group’s bailiwick. The group’s powers and responsibilities remain unchanged, although it would be reasonable to expect the group to take into account the views of the HF.
26
-
</div>
27
-
<div>
28
-
We make a distinction between projects and committees.
Affiliation means that the group supports the goals of the Haskell Foundation, and, in return, the Haskell Foundation supports this group.
18
+
</div>
19
+
<div>
20
+
Different groups work in different ways, and it would be counter-productive to impose complete uniformity. However, we expect the groups that want to affiliate with the Haskell Foundation to follow a few ground rules, laid out below.
21
+
</div>
22
+
</div>
23
+
<divclass="space-y-8">
24
+
<div>
25
+
Affiliation does not mean that the HF is taking over control of that group’s bailiwick. The group’s powers and responsibilities remain unchanged, although it would be reasonable to expect the group to take into account the views of the HF.
26
+
</div>
27
+
<div>
28
+
We make a distinction between projects and committees.
29
+
</div>
32
30
</div>
31
+
33
32
</div>
34
33
</div>
35
-
34
+
</div>
36
35
37
36
<divclass="max-w-screen-xl mx-auto">
38
37
<divclass="mt-16 md:mt-24">
39
38
40
-
<divclass="px-4 sm:px-8 md:px-12 lg:px-16">
41
-
<divclass="mx-auto prose md:prose-lg">
39
+
<divclass="px-4 sm:px-8 md:px-12 lg:px-16">
40
+
<divclass="mx-auto prose md:prose-lg">
42
41
43
-
<h2>Affiliated Committees</h2>
42
+
<h2>Affiliated Committees</h2>
44
43
45
-
<h3>Transparency</h3>
46
-
<ul>
47
-
<li><p>
48
-
Group must have some website that makes it clear what the goals and responsibilities of this group are
49
-
</p></li>
50
-
<li>
51
-
<p>
52
-
All technical discussions must be stored in a publicly accessible location, for example:
53
-
</p>
44
+
<h3>Transparency</h3>
54
45
<ul>
55
-
<li><p>
56
-
GitHub issues
57
-
</p></li>
58
-
<li><p>
59
-
GitLab issues
60
-
</p></li>
61
-
<li><p>
62
-
Mailing list archives There is an obvious exception for confidential matters such as financial and security related information
63
-
</p></li>
46
+
<li>
47
+
<p>
48
+
Group must have some website that makes it clear what the goals and responsibilities of this group are
49
+
</p>
50
+
</li>
51
+
<li>
52
+
<p>
53
+
All technical discussions must be stored in a publicly accessible location, for example:
54
+
</p>
55
+
<ul>
56
+
<li>
57
+
<p>
58
+
GitHub issues
59
+
</p>
60
+
</li>
61
+
<li>
62
+
<p>
63
+
GitLab issues
64
+
</p>
65
+
</li>
66
+
<li>
67
+
<p>
68
+
Mailing list archives There is an obvious exception for confidential matters such as financial and security related information
69
+
</p>
70
+
</li>
71
+
</ul>
72
+
</li>
73
+
<li>
74
+
<p>
75
+
It should be clear what decisions the group has taken, and what are under discussion (if it’s that kind of group). A good example of this are the GHC Steering Committee proposals, but a simple email to a public list can also suffice.
76
+
</p>
77
+
</li>
78
+
<li>
79
+
<p>
80
+
The group must have a voting system in place in case it cannot reach unanimity. Votes must be accompanied by reasoning, and a tie-breaking mechanism should be in place.
81
+
</p>
82
+
</li>
64
83
</ul>
65
-
</li>
66
-
<li><p>
67
-
It should be clear what decisions the group has taken, and what are under discussion (if it’s that kind of group). A good example of this are the GHC Steering Committee proposals, but a simple email to a public list can also suffice.
68
-
</p></li>
69
-
<li><p>
70
-
The group must have a voting system in place in case it cannot reach unanimity. Votes must be accompanied by reasoning, and a tie-breaking mechanism should be in place.
71
-
</p></li>
72
-
</ul>
73
84
74
-
<h3>Membership</h3>
75
-
<ul>
76
-
<li>
77
-
<p>
78
-
The group’s website should list its members (with their affiliations and terms), and the membership rules.
79
-
</p>
80
-
</li>
81
-
<li>
82
-
<p>
83
-
Groups should appoint a chair (or co-chairs) or a contact for Haskell Foundation.
84
-
</p>
85
-
</li>
86
-
<li>
87
-
<p>
88
-
Groups should ensure a turnover of membership, for example by setting terms.
89
-
</p>
85
+
<h3>Membership</h3>
90
86
<ul>
91
87
<li>
92
88
<p>
93
-
This only makes sense for "decision-making" bodies, not really for groups that just focus on doing work.
89
+
The group’s website should list its members (with their affiliations and terms), and the membership rules.
94
90
</p>
95
91
</li>
96
-
</ul>
97
-
</li>
98
-
<li>
99
-
<p>
100
-
The process for appointing new members should be clearly set out:
101
-
</p>
102
-
<ul>
103
92
<li>
104
93
<p>
105
-
There should be a “way in” for new members who are not already part of the “in crowd”; for example, a regular opportunity to self-nominate.
94
+
Groups should appoint a chair (or co-chairs) or a contact for Haskell Foundation.
106
95
</p>
107
96
</li>
108
97
<li>
109
98
<p>
110
-
Criteria for new members should be written down, so that new members can address them in writing a self-nomination.
99
+
Groups should ensure a turnover of membership, for example by setting terms.
111
100
</p>
101
+
<ul>
102
+
<li>
103
+
<p>
104
+
This only makes sense for "decision-making" bodies, not really for groups that just focus on doing work.
105
+
</p>
106
+
</li>
107
+
</ul>
112
108
</li>
113
109
<li>
114
110
<p>
115
-
A reasonably broad group of people should be involved in making appointment decisions (e.g. not just the chair). Typically the whole group votes on appointing new members.
111
+
The process for appointing new members should be clearly set out:
116
112
</p>
113
+
<ul>
114
+
<li>
115
+
<p>
116
+
There should be a “way in” for new members who are not already part of the “in crowd”; for example, a regular opportunity to self-nominate.
117
+
</p>
118
+
</li>
119
+
<li>
120
+
<p>
121
+
Criteria for new members should be written down, so that new members can address them in writing a self-nomination.
122
+
</p>
123
+
</li>
124
+
<li>
125
+
<p>
126
+
A reasonably broad group of people should be involved in making appointment decisions (e.g. not just the chair). Typically the whole group votes on appointing new members.
127
+
</p>
128
+
</li>
129
+
</ul>
117
130
</li>
118
131
</ul>
119
-
</li>
120
-
</ul>
121
132
122
-
<h3>CODE OF CONDUCT</h3>
123
-
<p>
124
-
Groups must adopt the <ahref="/guidelines-for-respectful-communication">Guidelines for Respectful Communication</a>. Groups may additionally adopt other guidelines & CoCs that are stronger; as long as they do not conflict with the GRC.
125
-
</p>
126
-
<p>
127
-
Why make a code of conduct as part of HF affiliation?
128
-
</p>
129
-
<ul>
130
-
<li>
133
+
<h3>CODE OF CONDUCT</h3>
131
134
<p>
132
-
We want the Haskell community to be welcoming, diverse, and inclusive. Having explicit guidelines for respectful communication signals that desire, and makes it more explicit and concrete.
135
+
Groups must adopt the <ahref="/guidelines-for-respectful-communication">Guidelines for Respectful Communication</a>. Groups may additionally adopt other guidelines & CoCs that are stronger; as long as they do not conflict with the GRC.
133
136
</p>
134
-
</li>
135
-
<li>
136
137
<p>
137
-
For all of us, as individuals and as groups, making an explicit commitment to respectful communication encourages us to review our messages to see if they meet the goals set out in the guidelines, and will give others some specifics to point to if we fail.
138
+
Why make a code of conduct as part of HF affiliation?
138
139
</p>
139
-
</li>
140
-
</ul>
140
+
<ul>
141
+
<li>
142
+
<p>
143
+
We want the Haskell community to be welcoming, diverse, and inclusive. Having explicit guidelines for respectful communication signals that desire, and makes it more explicit and concrete.
144
+
</p>
145
+
</li>
146
+
<li>
147
+
<p>
148
+
For all of us, as individuals and as groups, making an explicit commitment to respectful communication encourages us to review our messages to see if they meet the goals set out in the guidelines, and will give others some specifics to point to if we fail.
149
+
</p>
150
+
</li>
151
+
</ul>
141
152
142
-
<h2>Affiliated Projects</h2>
153
+
<h2>Affiliated Projects</h2>
143
154
144
-
<ul>
145
-
<li>
146
-
<p>
147
-
The project must have a public issue tracker and/or mailing list where discussion about the project takes place
148
-
</p>
149
-
</li>
150
-
<li>
151
-
<p>
152
-
The expectation is that the project has at least one responsive maintainer. If this is not the case, it should be clearly signalled that more resources are required.
153
-
</p>
154
-
</li>
155
-
<li>
156
-
<p>
157
-
The project must be open to community discussion about possible features and contributions.
158
-
</p>
159
-
</li>
160
-
<li>
161
-
<p>
162
-
The project should encourage new contributors and members, i.e. there should be "a way in".
163
-
</p>
164
-
</li>
165
-
<li>
166
-
<p>
167
-
Just like committees, the project must adopt the <ahref="/guidelines-for-respectful-communication">Guidelines for Respectful Communication</a> as a code of conduct.
168
-
</p>
169
-
</li>
170
-
</ul>
155
+
<ul>
156
+
<li>
157
+
<p>
158
+
The project must have a public issue tracker and/or mailing list where discussion about the project takes place
159
+
</p>
160
+
</li>
161
+
<li>
162
+
<p>
163
+
The expectation is that the project has at least one responsive maintainer. If this is not the case, it should be clearly signalled that more resources are required.
164
+
</p>
165
+
</li>
166
+
<li>
167
+
<p>
168
+
The project must be open to community discussion about possible features and contributions.
169
+
</p>
170
+
</li>
171
+
<li>
172
+
<p>
173
+
The project should encourage new contributors and members, i.e. there should be "a way in".
174
+
</p>
175
+
</li>
176
+
<li>
177
+
<p>
178
+
Just like committees, the project must adopt the <ahref="/guidelines-for-respectful-communication">Guidelines for Respectful Communication</a> as a code of conduct.
0 commit comments