MODX 3 - New Feature Request System

Thx JP. A bug fix release I guess.

JP I just realized that you were the author of this very well-articulated post on the future of MODX. It pretty much sums up what I said earlier. It's an excellent piece by the way.

2.3 should actually be more than just bug fixes. There are a few key features I know are being worked on. I have limited knowledge, but I think making Package development (using namespaces) a simpler process, and in theory making ArrayTV (MIGX like TVs) native
Quote from: treigh at May 05, 2013, 04:23 PM

Thx JP. A bug fix release I guess.

I thought the voting system was launched last year already. It was mentioned in this blog post.

http://modx.com/blog/2012/09/11/the-modx-innovation-process-putting-penguins-in-a-suitcase/

Perhaps in the next few weeks ...

It's actually great that it was planned. I read that blog post some time ago, but I guess I didn't pay attention to the voting part. In the end what really matters is involvement. I'm a big fan of anything that'll work to advance the cause better than before.

I'd love to use github instead of redmine. So much simpler with a much better UI than redmine. And I don't think we need all those bells and whistles redmine gives us.

Quote from: markh at May 06, 2013, 06:10 AM

I'd love to use github instead of redmine. So much simpler with a much better UI than redmine. And I don't think we need all those bells and whistles redmine gives us.

I'd certainly be curious in how many think using GitHub issues is a good or bad idea moving forward, along with some justification for why you think so.

@opengeek Github has a strong brand awareness and that's its main advantage. It's got an excellent UI as Mark pointed out and to paraphrase an earlier post, it does broaden the target market for any project.

That said, what's being proposed is not a regular Github project, at least not until it serves its purpose. I do believe that we have a very selective target audience when it comes to brainstorming for the future breakthrough software that could be MODX 3. I don't think we need millions of potential users from across the web with billions of ideas. What we do need is group of dedicated MODX users who already know what works and what doesn't and many of them may not be used to Github just yet. From an efficiency perspective, this offers the advantage of being goal-focused.

The other pro for an in-house solution is community involvement. The everyone-needs-to-step-up sermon has been well-preached by virtually everyone who cares about MODX. It's time to give people a chance to mean what they say.

Don't get me wrong. Github is awesome. Especially for the initiated ones but I fear it might be intimidating for neophytes. I'm not advocating for Redmine per se, but I'm more for an intuitive, well-crafted, community-centered and easy to manage in-house tool - whatever it might be.

In the end those two options aren't necessarily mutually exclusive. Nothing prevents anyone from submitting ideas via the MODX project page on Github and still be engaged in the community-oriented tool.

I could be wrong, but that's the beauty of a discussion.

@treigh

What do we see as the ideal interface/forum for such proposals and corresponding discussions? I've argued against using dev tools for this type of thing because, as you highlight, it is intimidating to people who are not familiar with such tools. Honestly, Redmine's UI is pretty sad and with small fonts and too many fields, people would rather just not bother. Tools like UserVoice or GetSatisfaction, do provide such a forum for feature proposals and discussion though I am personally not fond of voting and polls when, lots of people vote for a feature that is out of sync with the product vision or one person suggests something nobody else has ever considered and it's ignored because the voting favours against it's integration (not that you have to follow the demands of the voting members).

Github is becoming more mainstream. I am seeing writers and non technical folks using it for versioning things other than source code.

Perhaps all we need is to define the fields we need and how we want to discuss this and what features it needs. Could a customized version of Discuss work with voting added? I am thinking these types of discussions/proposals are usually more preliminary than a simple FR but perhaps not. If it somehow needs to be able to be converted to a FR ticket, perhaps that could be a custom api connection that could be added. IDK.

Jay--

Thanks for the insight. You make an excellent point on the downside of voting and stuff. The last thing we want is to lose sight of what's essential.

I guess I'm finally sold on Github.

Once we have some sort of Blueprint for MODX 3, I'm sure there'll be a lot to propose.