We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 18373 ☆ A M B ☆
    • 3,141 Posts
    Let me clarify my earlier opinion; I don't want to suggest moving product discussions to github, however bugs (the main thing redmine should be helping with) IMO could very well be moved there. We've got a forum that should be a platform for discussions about product direction and speccing out features, while github could be the platform to maintain the list of bugs. Of course discussion of the bugs would be perfect there tongue
      Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

      Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
      • 38290
      • 712 Posts
      Some pros of Github for bug tracking I see:

      • it's GitHub
      • awesome markdown syntax
      • visualization

      Visualization is the most important. I understand the concern for GitHub maybe being too technical but, is redmine not?

      He's the difference in UX between the two:
      Redmine - this interface isn't that sleek and all I see are a ton of open, old bugs. Is this project still being worked on?
      GitHub - woa I'm part of a community all of a sudden. This interface is awesome, and I can see right here what the MODX team has been working on lately. Look at all these pull requests, this thing is very much alive. Even though there are a bunch of open bugs, I feel good contributing to it now.
        jpdevries
        • 9207 ☆ A M B ☆
        • 2,475 Posts
        I *hate* Github's markdown -- it's the absolute worst one available if you're trying to post any MODX template syntax, and I've tried a LOT of trackers. Square-brackets and the like get absolutely murdered. Google Code, Redmine, or Jira are much, much better at this. I'm considering moving some of my MODX projects off of Github simply because its markdown is so fantastically bad.

        I'd say the same is broadly true with Github's bug reporting. Redmine may not be perfect, but it doesn't screw things up. Github has the glitz-factor, but really, are we myopically prioritizing aesthetics over functionality? Being able to post code samples is HUGELY IMPORTANT, and Github is just awful for this, especially with the MODX syntax. I don't care if it's the most popular site on the planet: I can come up with a thousand critical ways where it fails in about an hour.

        I can draw an analogy with WordPress: "Oooo! Pretty! I want that!" and then the developer opens up his code editor, his wrists are chained to his ankles, and his is lowered into the stinking cesspool that is WordPress' PHP.

        There must be a healthy balance between solid functionality and good UI/UX.
          • 38290
          • 712 Posts
          Quote from: Everettg_99 at May 10, 2013, 12:20 AM
          I *hate* Github's markdown -- it's the absolute worst one available if you're trying to post any MODX template syntax, and I've tried a LOT of trackers. Square-brackets and the like get absolutely murdered. Google Code, Redmine, or Jira are much, much better at this. I'm considering moving some of my MODX projects off of Github simply because its markdown is so fantastically bad.

          These seem to work ok:
          [[+content]] [[*content]] [[++content]]

          Can you give an example of something in the MODX tag syntax that isn't Github markdown friendly?
            jpdevries
            • 3749
            • 24,544 Posts
            For those not aware of it, this is a great tool for working on GitHub markdown: http://daringfireball.net/projects/markdown/dingus
              Did I help you? Buy me a beer
              Get my Book: MODX:The Official Guide
              MODX info for everyone: http://bobsguides.com/modx.html
              My MODX Extras
              Bob's Guides is now hosted at A2 MODX Hosting
              • 9207 ☆ A M B ☆
              • 2,475 Posts
              [[+content]] [[*content]] [[++content]]


              A perfect fail: http://www.screencast.com/t/mHqVS5FMbdnq (see attached as well).

              GitHub's buttons rarely work (e.g. format as code, italics, bold) -- I even submitted some bug reports to GitHub and they acknowledged that they had a problem, and then they proceeded to do absolutely nothing about it, so my confidence with them is pretty low.

              The only markdown option that's remotely palatable is the AsciiDoc syntax:
              http://www.screencast.com/t/jwKhUk8Ks1x

              But again, the buttons there pretty much are useless, the "?" button includes instructions that are flat out wrong or devastatingly incomplete, and the manual formatting options are quite limited with AsciiDoc, so your documentation has to be constrained to simplistic outlines and your users suffer from loss of clarity.

              GitHub acknowledged problems with its AsciiDoc parser specifically. I could go on, but really, I've wasted days of my life trying to make GitHub work and trying to get on board with it, but I've realized that it doesn't really have it where it counts in my opinion, and that's about as civil as I can be in my comments about it.
                • 38290
                • 712 Posts
                For GitHub WikiPages using Markdown Editor type looks like you just need to use HTML Entities instead of tags, and escape your backticks.

                Example:
                https://github.com/jpdevries/Cachebuster/wiki/Usage

                Source:
                https://gist.github.com/jpdevries/5f3924a3bfb78b1be6d3
                  jpdevries
                  • 9207 ☆ A M B ☆
                  • 2,475 Posts
                  Nice. I played around with that for days and never got that to work, but that sorta proves my point. As Han Solo famously never said: "Hokey markdowns and ancient entities are no match for a good pre tag at your side, kid."

                    • 30585
                    • 833 Posts
                    @jpdevries and @Everett, interesting discussion.

                    I'm curious to know others take on this. It surely looks like this issue is far from settled. Jay Gilmore seemed to prefer Github, while Jason (Opengeek) wanted the to get a pro-con analysis from the rest of us. Mark Hamstra also prefers Github, but others do seem to favor a different offer. It may not be Redmine, which isn't very popular, but it'd be interesting to hear from others.

                    This is definitely worth discussing.
                      A MODx Fanatic
                      • 9207 ☆ A M B ☆
                      • 2,475 Posts
                      I'll take a stab at a pro/con:

                      Github

                      PROS: social aspect, cool-factor, forks and pull-requests makes it easier to handle multiple contributors.
                      CONS: limited markdown, simplistic bug-reporting, disorganized wikis.

                      Redmine

                      PROS: clean, good markdown, organized Wikis, Gantt charts, superior control for issues/features: there's accountability and prioritization and due dates.
                      CONS: boxy, does not inherently support social coding (e.g. forks, pull-requests, diff patches etc).

                      I know for me, I would lose my mind if I tried to manage any large scale project via Github. Redmine is much better suited to handling bugs and feature requests because you can track time, assign priorities, you can define how you spent your time on a given issue (e.g. developing or doing research) -- in short, Redmine offers the kind of depth and accountability that any organization/large-project requires. I just don't see that with Github... there may be some people using it that way, but but more often I see large projects using Github solely as their repo and handling the ticketing and documentation somewhere else. I haven't tried integrating a Git repo with Redmine, but I know it's possible -- that might be more fertile, but I know I'd miss the fork/pull-request model from Github. Other than that, I just don't see what the hubbub is about.... SVN and .diff patches would effectively provide the same functionality.