Running/contributing to an open source project



  • +10 for clear bug reporting guides. Not a dev, just a tester here. But I know how helpful it is to you guys. It might be worth some of us QA types managing the bug tracker to

    1. Make sure multiple bug reports all get sorted to the same issue.
    2. Make sure all the bug reports make sense and are in clear English.
    3. Have a go at prioritising the bugs.


  • Thanks a lot all. Some great links and things to follow up on here. I think I like the git-flow style, and a transition to git may be in order, if we can sort the large file issue.



  • What are you using right now?



  • they use svn



  • @Mantolwen I highly agree with all of that especially well formed responses on bugs. As someone who's spent more time just trying to figure out what a client even wanted to ask themselves vs making sense of what they already asked / reported an issue on, it can be a lifesaver if the bug report is well organized / has its own monitoring for control. Especially if say a particular bug is reported multiple times across the board we would need to up its priority level of a 'fix' vs a bug reported only once.

    With that said i'm now even envisioning a means of 'up voting' or 'liking' on a bug if someone already filled out the details and you just need to re-iterate it when you came across it yourself (if it still not fixed yet).



  • I just want to add to there comments and say I am super eager to learn Unity to help like many others are, but am not sure where to start, so a "Getting Started" guide would be awesome! I could help put together and design a PDF or something with others if there is interest.



  • Bug reporting is easyer with the full source code. Reason for that is you can Just run the game in debug anddrill into the bug yourself and better can report a bug(tho this also means those having acces need to be able to debug. Bug fixing should be the core devs responsebility



  • Bug reporting is easyer with the full source code. Reason for that is you can Just run the game in debug anddrill into the bug yourself and better can report a bug(tho this also means those having acces need to be able to debug. Bug fixing should be the core devs responsebility



  • Just in case you guys are new to Git, I find everyone has a different way of using it. I'd been console only for years until I started a job at a place with 300 odd devs and GitHub enterprise. Here's some of the stuff we do...

    If it's GitHub then it's generally GitHubFlow, a variant of GitFlow which includes pull requests.

    Learn to rebase your local updates - it makes the history much more readable and will make your pull requests way smaller (when you encounter this pain, you will understand what I mean).

    <code>git rebase -i <target branch></code> will start an interactive rebase (the best kind) by bringing up a textfile with instructions - it's worth just trying it out and seeing what happens (with a test repo).

    <code>git rebase --ignore-date <current base branch></code> will rewrite all of your commits to now so they're all nicely grouped together in the history.

    A lot of people don't seem to twig that any git repo directory is a valid target for a remote - super handy for working on two versions of code or exchanging code without the rigmarole.

    It seems like GitHub Desktop is the GUI tool to use these days. GUIs help because they conventionalise merge, rebase and conflict commit messages.

    https://github.com/nvie/gitflow - the console tools for git (hub) flow by the guy who came up with it.
    If you use this, you'll get automatic release notes simply through the way it integrates with Git's tag system and how GitHub presents them.

    https://github.com/GitTools/GitVersion - .NET tools for getting different formats of code version from the git history - super useful for CI

    Change your git text editor and diff tool to something you might actually want to use.
    kdiff3 is decent and pre-configured if you're after a free diff tool.

    Get line endings sorted in a .gitattributes file and get a white-list style .gitignore because it is very hard to get rid of unwanted files once they make their way into the repo.

    PuTTY is pretty key in Windows for not having to enter the password for your ssh key all the time.



  • Thanks for the writeup Seth! So far been loving the github/visual studio integration.


Log in to reply