Giter VIP home page Giter VIP logo

neil's Introduction

Neil: Workflow Utilities Hackage version Build status

A tool for performing common actions run by Neil Mitchell. Many of these commands enhance specific aspects of my workflow. While other people are welcome to use this tool, it is not supported. Use neil --help to see what is available. Some uses:

  • neil docs can be used to upload documentation to Hackage, as per this blog post.

Contributions

These guidelines apply to all my projects, not just this one. I am pretty relaxed, but as guidelines to my preferences:

  • I welcome and appreciate contributions. If you've contributed to my code, and we meet in real life, I'll buy you a beer.
  • GitHub pull requests are the preferred mechanism for sending me code.
  • If writing the code will take a significant amount of time, please raise a ticket first, so we can discuss possible approaches and whether I agree with the direction. I'd rather give advice before people use their valuable time, than after.
  • That said, if you have a pull request that fixes something, don't bother raising a separate ticket - just the pull request is fine.
  • If you go down a few dead ends and have a few junk commits in there, don't worry, as long as they don't stray too far outside the area you were working on. No need to squash the history.
  • If I am not responding after a few days, ping me again on the ticket, or via email. I'm probably just busy or lost the email in a pile. I certainly intended to thank you for contribution and give some feedback.
  • If your preferences are vehemently different, then follow yours, I'm really not all that fussed - but sometimes it's easier for people to know what you do like rather than to spend effort thinking about what you like, or doing something they think you will like but you actually don't.
  • After I've merged your patch, if it would be useful to have an immediate release containing the patch (e.g. because you are working on downstream code or can only deploy official releases in production) let me know. Usually I am happy to release after any change, but for smaller changes might wait to collect a bunch of things together.
  • I develop on master and only update the .cabal version just before a release. I don't expect submitted PR's to update version numbers.
  • I require all contributions to my repositories to be licensed under the license of that project.

Quirks

There are a few places where my opinion on coding differs from other people, so I document them here so as not to cause surprise:

  • I tend to be conservative in my use of extensions. If the project doesn't already use type functions/GADTs, then unless they add compelling benefits, I'm probably not going to like them.
  • I am conservative in my use of additional packages, since each additional package complicates a project. I tend to not use upper bounds unless I think they are particularly valuable, but do so on a package-by-package basis.
  • I avoid CPP where possible, trying other techniques to work around API changes through versions.
  • Where I do use CPP, I make sure the code still loads in ghci alone, if all MIN_VERSION_foo macros have not been defined.
  • I don't use explicit imports, since I consider the benefits small, but the cost of continually editing imports while developing to be a significant distraction to the flow of coding.
  • I stick to ASCII characters, since I appreciate the ease of typing and complete editor/font compatibility.
  • I avoid literate Haskell and boot files, both of which offer significant complexity.
  • I don't add stack.yml files if they would be identical to those produced by stack init. I do test that stack init works and builds correctly.
  • I try and push my testing to the limit, checking things like timing properties and the copyright year etc that are inherently fragile. As a result, sometimes the tests will fail. That tends to be a transient state, but don't overly worry if tests fail after a PR.

neil's People

Contributors

cotrone avatar daniel-diaz avatar jmitchell avatar kristianbalaj avatar kritzefitz avatar ndmitchell avatar shayne-fletcher avatar toelli-msft avatar tomjaguarpaw avatar

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.