<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<style>
<!--
@font-face
{font-family:Wingdings}
@font-face
{font-family:"Cambria Math"}
@font-face
{font-family:"Yu Gothic"}
@font-face
{font-family:Calibri}
@font-face
{}
p.x_MsoNormal, li.x_MsoNormal, div.x_MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif}
a:link, span.x_MsoHyperlink
{color:blue;
text-decoration:underline}
a:visited, span.x_MsoHyperlinkFollowed
{color:#954F72;
text-decoration:underline}
p.x_MsoListParagraph, li.x_MsoListParagraph, div.x_MsoListParagraph
{margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif}
.x_MsoChpDefault
{}
@page WordSection1
{margin:70.85pt 3.0cm 70.85pt 3.0cm}
div.x_WordSection1
{}
ol
{margin-bottom:0cm}
ul
{margin-bottom:0cm}
-->
</style>
<div lang="EN-GB" link="blue" vlink="#954F72">
<div class="x_WordSection1">
<p class="x_MsoNormal">Hello;<br>
<br>
I’d like to ask something regarding this effort. Right now, GHC’s repository is mirrored in these locations:</p>
<ul type="disc" style="margin-top:0cm">
<li class="x_MsoListParagraph" style="margin-left:0cm"><a href="https://phabricator.haskell.org/diffusion/GHC/">Phabricator</a></li><li class="x_MsoListParagraph" style="margin-left:0cm"><a href="https://git.haskell.org/">git.haskell.org</a></li><li class="x_MsoListParagraph" style="margin-left:0cm"><a href="https://github.com/ghc/ghc/">GitHub</a></li><li class="x_MsoListParagraph" style="margin-left:0cm"><a href="https://gitlab.haskell.org/ghc/ghc/">GitLab</a></li></ul>
<p class="x_MsoNormal"> </p>
<p class="x_MsoNormal">Most of these have associated READMEs that encourage users to contribute patches to that particular instance, which does not really reflect the current state of affairs: right now, it is my understanding that GitLab is where all (new)
patches are to be submitted.</p>
<p class="x_MsoNormal"> </p>
<p class="x_MsoNormal">With the recent migration to GitLab and archival of Trac, will the first two be moved to read-only status like the Trac service?<br>
<br>
Regarding GitHub/GitLab – do we still want to accept contributions to GitHub? If so, what kind? All kinds? Maybe just small documentation patches?</p>
<p class="x_MsoNormal"> </p>
<p class="x_MsoNormal">I believe all of this should be documented to avoid fragmentation of contribution efforts. I still remember my first contribution was a little confusing because of this.</p>
<p class="x_MsoNormal"> </p>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> ghc-devs <ghc-devs-bounces@haskell.org> on behalf of Tobias Dammers <tdammers@gmail.com><br>
<b>Sent:</b> Tuesday, March 5, 2019 11:54:34 AM<br>
<b>To:</b> GHC Devs<br>
<b>Subject:</b> Re: Newcomers' Guide to GHC Development</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:11pt;">
<div class="PlainText">Hi, thanks for your feedback.<br>
<br>
I'll get into some detail below.<br>
<br>
On Sat, Mar 02, 2019 at 11:36:06AM +1100, Julian Leviston wrote:<br>
<br>
> The updated version could be improved by shaping it into clearer<br>
> sections because we’d like newcomers to feel like it’s light and easy.<br>
> Layers is a great way to achieve this.<br>
> <br>
> The first time I ran through the task list (not very long ago), it<br>
> felt light and easy. This was because it was chunked well.<br>
> <br>
> So, my suggestion would be to have a third sentence/paragraph in the<br>
> introduction section that explains what the overall steps are that<br>
> we’re going to explain next. Provide links down into those sections,<br>
> and make it really clear that those sections are sections, if<br>
> possible.<br>
<br>
I like the idea of a short outline of the overall progression in the<br>
introduction, so just added that. I won't add those links yet, because<br>
due to the way this works in Gitlab, it's best to do it after the<br>
document has solidified, because adding or removing headers (of any<br>
level) will change the headers' generated ID properties, potentially<br>
breaking any links.<br>
<br>
As far as the chunking goes, I believe we already have a fairly decent<br>
structure in place. The GitHub layout may not make it very obvious<br>
though, and I think it'll be clearer on Gitlab. I did rearrange things a<br>
tiny bit in order to fit in better with the overall arch though.<br>
<br>
If you have concrete suggestions on how to improve the structure<br>
further, please feel free to tell, or better yet, issue a PR on GitHub.<br>
<br>
> At each section, you could reiterate how to do that driving from the<br>
> overarching aim of the explanation for the section. (Having an<br>
> introduction to each section would help here, too).<br>
<br>
This seems like overkill to me. We need to strike a balance between<br>
completeness and brevity, and we're bordering on "too long" already. I<br>
did try to come up with suitable introductions, but they all ended being<br>
paraphrasings of the title or the entire section, so I decided against<br>
them.<br>
<br>
Note that my goal here is to remove obstacles and friction, not to<br>
persuade people into contributing - by the time you read this guide, you<br>
should have been persuaded already.<br>
<br>
Quoting the very first sentence in the guide:<br>
<br>
| This page is intended to serve as the first stop for those people who<br>
| say, "I want to contribute to GHC, but I don't know quite where to<br>
| begin."<br>
<br>
<br>
> For example, having a canonical way to determine what a good issue or<br>
> feature to start on would be awesome, as would having somewhat of a<br>
> mentor/buddy to help new users when working on their bugs (ie one or<br>
> two people assigned to a newcomers’ first two or so tickets to help<br>
> them through any issues until they feel confident). Not sure if our<br>
> contributors allow for such things yet, tho.<br>
<br>
I agree that that would be awesome; however, we have limited resources<br>
at our disposal that we need to juggle between several concerns, and<br>
mentoring newcomers is only one of them.<br>
<br>
What we can offer right now is:<br>
<br>
- Issues labeled "newcomers" (the guide already mentions these)<br>
- Ad-hoc, no-strings-attached support from core GHC contributors and<br>
various volunteers via this mailing list and IRC (the guide mentions<br>
these, too)<br>
- Some time from core contributors, as available, allocated to handling<br>
incoming issues and merge requests. We strive to provide feedback on<br>
every one of them, but we cannot make any hard promises as to the<br>
timeframe, and we have to prioritize.<br>
<br>
On top of that, many individuals and third-party organisations run<br>
various forms of mentoring, tutoring, guidance, hackathon events,<br>
counseling, etc. Listing those would go way beyond the scope of this<br>
document, but you should have little trouble getting suggestions via our<br>
various communication channels.<br>
<br>
Hope that clarifies things, and again, thanks a lot for your input.<br>
_______________________________________________<br>
ghc-devs mailing list<br>
ghc-devs@haskell.org<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</div>
</span></font>
</body>
</html>