In a sweep to make sure that the concerns raised here get heard, I see this great list of suggestions. I believe they have all been incorporated into https://github.com/ghc-proposals/ghc-proposals/pull/9, so please check there. Personally, I think these suggestions will get better discussion and be more actionable if broken up into smaller PRs that can easily be debated separately. However, I will leave it to others to make this decision and do the restructuring.
Thanks for these suggestions forward! Richard -=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae <http://cs.brynmawr.edu/~rae> > On Sep 26, 2016, at 2:37 AM, loneti...@gmail.com wrote: > > Hi All, > > I wanted to give my own thoughts/suggestions for things we could do on the > short/medium term > To make things a bit better. As a whole I may be one of the few who likes the > current setup so I > Propose enhancing the current toolset. > > I find the mail patch to mailing list approach of GCC et al quite cumbersome > to be honest. > And the discussion quickly becomes hard to follow as it branches lot. > > My proposals (sorry for the brevity, I can expand if needed): > > * Link phab to github > Phabricator seems to have build in OAuth support. > As you'll likely need a github account anyway, why not > also support github logins? This would reduce the barrier of > needing multiple accounts that is often a complaint. > Would it be possible to maybe also extract the user's public > key from github automatically? That would reduce one of the barriers as well. > https://secure.phabricator.com/book/phabricator/article/configuring_accounts_and_registration/ > > <https://secure.phabricator.com/book/phabricator/article/configuring_accounts_and_registration/> > > * Link Trac to github > - used to login (OAuth support) > - readonly issues (to begin with?). > we already have a code mirror, why not mirror more content. > - sync issues back between the two > - gives us an ability to see which github users an issue affects > since they can then reference it. > - updates the users when an issue is fixed since it will be closed on GH. > - Gives us an indication of the importance of the tickets > > As a whole, I find Trac MUCH better for ticket triaging than Github or Phab, > both of which seem to be quite bare and simple in what they provide. I am not > in favor of ditching it. Also we have and continue to accept patches just > uploaded > to Trac as a diff. We tend to ask people to upload it to phab for better > reviews > and so it's attributed to them when we commit. Some don't (and we then do it > ourselves), > most due. If they don't need another login then I suspect almost all would. > There's a (seemingly) actively maintained project that does all the above, > could we leverage it? > https://github.com/trac-hacks/trac-github > <https://github.com/trac-hacks/trac-github> > * There is a trac plugin to generate a new section on trac > /doc which allows you to render and edit documentations checked into repo. > Could this be used to allow easier editing of non generated documentation? > > It's currently based on SVN, but maybe a git one exists too? > https://github.com/trac-hacks/tracdocs > <https://github.com/trac-hacks/tracdocs> > > * Newcomers > - Expose newcomers information more by creating a new landing page > - Clean up build instructions. For windows, I have scripts to automate setup. > Often heard complain is that it is hard, but never hear why it's hard. > > In any case, my setup script for a 100% unattended build env setup for > Windows > are here: https://github.com/Mistuke/GhcDevelChoco/releases > <https://github.com/Mistuke/GhcDevelChoco/releases> > > These are entirely self contained environments that can be removed by a > simple rm -rf /. > You can have as many as you want on the same machine without them > interfering with eachother > or with whatever else you might have done to your GHC already installed. > > It's not 100% production ready but it works and does so well. > > * Updated Phab reviewers list to be more automated > - Assign reviewers next to the static list (as is currently done) > to maybe also include significant contributors to that file? > > The reason for this is that currently it's always the same people > reviewing patches. > Their time is spread thin. Particularly on less popular platforms it > basically comes > down to 4 people. > * Update trac linters and pre-commit linters to be the same. > - particularly reject summaries that would be rejected on commit. > Often when I try landing patches (especially from others) I have to > edit the summary. Maybe arc should reject the diff if a push would fail? > > Also I want to say I love the summary document you have to fill in. > It ensures useful information is there later when I have to find out why > a change was made. So whatever we do, don't remove this. > > * Phab plugin to on signup ask for public key if none found. > - It's recently been made a requirement to require a public key to push to > phab. > The error you get when you don't do this and try to push a patch is very > very > cryptic and unintuitive. Could we make a plugin that asks the user to > upload > a public key on trac if they haven't done so? Like a banner at the top? > > * Automate trac tickets > - Particular on new tickets post a friendly reminder that if they want they > can give it a hand in fixing it themselves. > - Parse information added, in particular check if reproduction steps are > there etc. > - If stack is used, kindly ask if a repo without can be used. The amount of > bug reports with stack is increasing and regardless of my own opinion on the > tool, these reports are not very useful as is. > - Maybe automatically CC people from a pool based on the information in the > ticket? I tend to miss tickets because my filters are quite strict. Generally > if the ticket doesn't mention my name, is directed at me or has "Windows" in > the body somewhere it will skip my inbox. I review filtered tickets only once > a week. > - If a newcomer assigns a ticket to themselves, have trac automatically post > links to useful pages: > * how to setup build environment. > * how to get help > * assign a mentor? > * after x amount of time with no progress, remind them again that help is > available > > Kind Regards, > Tamar > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org <mailto:ghc-devs@haskell.org> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
