New subject: How, precisely, can we improve?

25 Sep 2016

      Richard, thank you for trying to give this some technical basis.

As someone who as contributed some tiny bugfixes to ghc, I found the process a bit cumbersome, yet manageable[1]. I’d
however like to propose some concrete changes, and please excuse if these have been discussed and found to not be actionable.

What I’d really like to see improved is the “multiple (web)services, multiple accounts” issue solved. As it is right now
I need to have a github account (ghc-proposals, soon tiny PR against ghc), a trac account (for the wiki and issue tracker;
which never seems to remember me), a phabricator account[2], likely a stack overflow account for questions and answers. On
top of that I also need to be on a large set of mailing lists if I want to not miss anything, and an irc client and 
twitter client to tap into the most recent discussions. And there’s another wiki on haskell.org for which I would need to
sign up and get an approved account.

I’d like to see the following:

1. Unify the issue tracker and code review into phabricator. Hence *if* I want to contribute to the ghc codebase, I essentially
  only need a phabricator account[3].  And a simple one page website on haskell.org that runs me through the “Contributing to
  GHC” as in:
...
GHC Development is facilitated through phabricator.
Please go to https://phabricator.haskell.org[4] and
create an account.
If you want to report a bug, please file a bugreport through
the “Maniphest” module, you can find on the left.
If you are looking for something to contribute, and browse the
Open Tasks at https://phabricator.haskell.org/maniphest/query/open/[5]
Clone the GHC tree and build it
[ clone and build instructions here; note about stage2 pinning to reduce compile times and other
 build system features ]
Hack to your hearts content on GHC (you might get some quick responses
regarding ghc’s internals at irc://irc.freenode.net/ghc, as well as in
the ghc commentary at …[6], or the ghc-dev mailing list for which you
can sign up at ...)
Validate your build [ plus instructions how to do so, and how to run
performance measurements on the changed ghc; if one is interested in
that as well ]
Upload your patch to GHC using the arc command line tool. You will have
to set up your token during the first use, just follow the instructions.
To upload your patch, commit your local changes; and run
$ arc diff origin/master
arc will run a few linters against your diff, and provide you with a form
to fill in all the details regarding your patch. This form is usually
prepopulated with the commit messages from your local commits.
During the review process you might have to update your diff. To do so
you can rebase your changes against the most recent master and/or add
additional commits to it; once you are done updating your patch, run
$ arc diff --update
Once your diff has been accepted, someone with commit rights with “land” your
diff into the official ghc tree.
And have this prominently liked from https://www.haskell.org/ under “Contributing”

2. Move the Wiki someplace else. I don’t know if the wiki in phabricator is any good, I’ve never used it.
  However, finding something in the ghc wiki has been more hit and miss for me than anything else. The
  built in search almost never reveals what I’m looking for, and resorting to a search engine only sometimes
  helps me find what I’m looking for. (This might totally be my fault).

3. Reduce the number of Mailing lists. I’m supposedly not on the haskell ml; so I missed
  https://mail.haskell.org/pipermail/haskell/2016-September/024995.html, and only saw it due to
  https://twitter.com/ezyang/status/780134457101516800.
  Are our MLs really that high volume that we need so many?

4. I like the idea of trivial pull requests to be accepted on GH as well. And I don’t see it as a big hurdle
  to ask someone to please be so kind and submit the patch through phabricator if it’s more involved with a
  link to https://www.haskell.org/contributing (see above).

In conclusion I’d like to propose to reduce the fragmentation of tooling, and accept the status quo of what
open source development seems looks like to many (github for code, stackoverflow questions (and documentation
soon?)) as much as we can.

Cheers,
Moritz

—

[1]: I didn’t understand phabriactor and arc in the beginning, however today I appreciate the process phabricator and
    arc offer a lot! (Over PRs)
[2]: for which you can actually use your bitbucket, github, twitter, … account.
[3]: I will also need some access to the staging area, if I want to use that feature.
[4]: Can we have http://phabricator.haskell.org redirect to https://phabricator.haskell.org? Instead of having both?
[5]: I guess one could create some Trivial, Easy, Medium and Hard queries.
[6]: This is currently scattered across the trac wiki.
...
On Sep 26, 2016, at 9:27 AM, Richard Eisenberg  wrote:
Like many of you, I'm sure, I'm saddened by the occasional tone of the recent exchange about contributions to GHC.
I'd like to move the conversation forward -- and I'd like to do so on a technical basis.
So, I ask:
How, precisely, can we improve?
I think it would be best to have answers to this question start their own thread, as I expect several good answers to this question.
As I ask this, I am not making the assumption that we cannot, nor is this meant to be rhetorical. I am asking a question in search of precise, technical answers.
"Be more like Rust" is not an answer to this question, as it is imprecise. (I'm not at all maligning the overall goal of emulating a successful process. It's just that "be more like Rust" is not actionable.)
"Accept PRs on GitHub" *is* an answer to this question, but one we have revisited several times in recent memory. (I believe https://mail.haskell.org/pipermail/ghc-devs/2015-September/009744.html is the most recent.) Perhaps we can revisit this yet again, but it would be great if new technical content can be injected into the debate. I hope the rejection of the proposal linked there is not considered "dismissive", as the proposal generated vigorous debate -- the opposite of dismissiveness. (For what it's worth, I'm weakly in favor of accepting PRs on GitHub. However, I have no experience setting up or maintaining infrastructure for an open source project and have happily deferred to those who have such experience and who have come out against this idea.)
"Have process (X) for accepting new language features" *is* an answer to my question. This is in flight and I hope addresses the concern in the community. It seems to me that this step addresses the grievances described in "The Process" part of http://www.arcadianvisions.com/blog/2016/ghc-contributing.html
"Have a formal mentorship system" *is* another answer to my question, and one I think we can readily adopt. Can you (for all values of "you") suggest a concrete model with a link? It seems to me that folks who ask for help get the help they need. But this surely requires the courage and wherewithal to ask for the help. Perhaps there is a better way to advertise our availability and desire to mentor. I, personally, have onboarded (or attempted to) several contributors and enjoy doing so. Though my ability to mentor wanes when I have gotten busy, I have always prioritized helping out the newest contributors, letting other, more confident actors' emails slip if necessary. If I have erred, I am sorry.
"Don't be dismissive" is not an answer to my question, as it is both imprecise and not technical. The most recent thread indeed had posts that seemed quite dismissive, but these posts emanated from people with a variety of viewpoints. It was hardly GHC HQ (whatever that means). What, precisely, has been dismissed? It looks to me that we (regular GHC contributors) take the community's concerns seriously. Fixes may be slow in coming, but that's not dismissiveness. Of course I'm biased here, but I am truly and earnestly asking for clarification.
Emboldened by the technical, respectful discussion recently on the merits (and usage patterns) of stack (starting at https://mail.haskell.org/pipermail/haskell-cafe/2016-September/124847.html), I look forward to a similarly technical, respectful discussion on our contribution process.
Thanks for all that you (for all values of "you") do to help grow our community and make it stronger.
Richard
-=-=-=-=-=-=-=-=-=-=-
Richard A. Eisenberg
Asst. Prof. of Computer Science
Bryn Mawr College
Bryn Mawr, PA, USA
cs.brynmawr.edu/~rae
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How, precisely, can we improve?

Michal Terepeta

Richard Eisenberg

Richard Eisenberg

Richard Eisenberg

Richard Eisenberg

tags

participants (16)