Should the Extra repo have better Moderation and Management

I don't think the forum topic is created automatically any more. At least it hasn't been for the last few extras I've submitted, and I don't think I've seen it since we switched to the native forum. I've been creating a post myself for them.


------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using.
MODX info for everyone: http://bobsguides.com/modx.html

What bothers me most about the repository is that the simple request of adding a description is largely ignored by many.

In the most basic sense, it seems that if no description is present, the package should be rejected. Is this not just a matter of a required field when submitting? Since I've never ventured into this process, I have no idea how it works or if it could be done.

Some great ideas in here. Most of which are things that the MODX team would like to put into place such as:

• Minimum criteria for Add-on acceptance
• Automatic Forum Thread Creation
• Ratings
• Handling of unmaintained add-ons such as adoption or special classification
• Better search and sort for add-ons based on factors such as activity, ratings, etc.

I will acknowledge that one of the key complaints about the terrible or inadequate descriptions was not rooted as much in the add-on author but in our submission forms. Up until about a month ago, a couple of the fields including the description, had vague labels/instructions for what content should be included. Since the change, I've seen improvements in the basic descriptions but some people are still inputting the version update information in the field. In my opinion we still have work to do on the Extras submission forms to make it absolutely clear as to what's expected.

There are some good points about private providers for developers to be able to have their own repository for use on their projects. I don't think this is a significant factor in the reason people submit extras. Many developers create add-ons in the course of a paid project and feel it would be of use to others and want to share their work. I'd suggest this is the vast majority of the people who contribute add-ons. Some developers are focused clearly on building high quality add-ons for the sake of the add-on itself because of a more general need but those developers are not the majority in any OS development community.

I see the desired outcomes here as:

• Making it easy to find high quality, well documented add-ons,
• Reduce the clutter of low quality, limited use add-ons,
• Setting standard criteria for add-on acceptance,
• Allowing users to rate add-ons,
• Managing add-on lifecycles,
• Allow users to report add-ons for compatibility issues or functional deficiencies,

Other thoughts for consideration:

• What should happen to useful add-ons who's original author has abandoned?
  [li]One what basis or criteria should add-ons be removed?
• In what ways could we encourage improvement of descriptions and docs for add-ons
• How do we prevent omitting good add-ons because a developer lacks the skills to clearly articulate the description or docs? (I often speak to people who can't clearly describe what they've built)

Thanks for all the comments everyone made. From all that I have read it all leads back to mainly the lack of documentation and description.

Jay I do agree with what you have written and would like to think that if an example of clear description and documentation was created then it would be easier for developers to follow. In that I mean probably a simple template outlining what a certain addon does and some description text.

I will try and answer some of the points you listed also below:

• What should happen to useful add-ons who's original author has abandoned?
In this case, MODX team could ask the community who is willing to take over development of the project, if no one takes on this responsibility after a year and the add-on is no longer compatible with the most widely used version of MODX in circulation, then it should be removed.


• On what basis or criteria should add-ons be removed?
This is a tricky one, I don't think they should be accepted in the first place without certain criteria being matched (saying so my add-ons would probably have been rejected based on the criteria's I am thinking of but it would have made me completed those criteria even more). I think the lack of documentation and proper description should result in the add-on failing to be accepted.


• In what ways could we encourage improvement of descriptions and docs for add-ons
Create more clear guidelines, create example documentation for others to follow.


• How do we prevent omitting good add-ons because a developer lacks the skills to clearly articulate the description or docs? (I often speak to people who can't clearly describe what they've built)
This can be solved by asking other members of the community to help documenting the add-on, plus I think if a developer can't describe what they have built, it leaves me worried about using that add-on.

Starting next week, I might cover some of the points listed above in order to help other developers who want to improve the MODX add-on repository.

Besides that there are many good points in all the previous posts, I will also suggest a more conservative approach to naming addons with "PL", although the basic features of these addons have not been tested thoroughly. (And therefore, they should probably really be marked as beta versions). There have been several of these that have caused many gray hairs - and even hair loss among users;-) (My self included!)

But it's also a problem that the documentation is becoming more and more fragmented: I also give courses in MODX, and even though my students can see the huge potential MODX have, they are typically scared by the detective work to find the documentation.

To find useful documentation we need to verify http://rtfm.modx.com, https://forums.modx.com, http://twitter.com, http://github.com, and - if we ever find it - the developer's own website, etc. It is too much!

It would be more user friendly if the documentation was located in one place! And more importantly: It will be easier to create a synergy in the development of new high quality addons. And bring MODX up in the league, which it really belongs!

As a more personal note, I'd be happy if all the addons in the "Package Management" has links to the documentation for the specific addon, and that these will open in a new window!

Jay's summary does very much reflect the changes I'd like to see implemented.

As for the points you brought up:

• What should happen to useful add-ons who's original author has abandoned?

It could perhaps be helpful if the author provided a link to the Github repository (or similar if one is used), either as a field when submitting (which would make it possible to add a link to it) or in the documentation. The latter being a thing people easily will forget.
Also they are still useful to users who haven't updated their installs and should perhaps be archived and only visible per specific criteria, such as compatible version range.

• On what basis or criteria should add-ons be removed?

This one is difficult to find the perfect solution for, but add-ons with next to no downloads and lacking documentation should be pretty high on the list. Other would be highly outdated ones (also difficult since they may be supported through backwards compatibility, but using deprecated methods).

• In what ways could we encourage improvement of descriptions and docs for add-ons

Would have to agree with Andrew on this one. Clear guidelines such as templates to help developers produce good documentation.

• How do we prevent omitting good add-ons because a developer lacks the skills to clearly articulate the description or docs? (I often speak to people who can't clearly describe what they've built)

This can be a problem for many, for example because of the language barrier. However, I think if they ask the community for help they might be able to atleast throw together a decent documentation. And if the developer published a link to a repository such as Github, the community would be able to directly help produce better documentation.

The repository would also help the community to update abandoned add-ons, and sometimes the repository holds a somewhat newer version that never got published.

I realize that not everybody knows how to use VCS like Git or SVN, but it could be a useful bit of information to have easily available for those who do, provided the developer used one in development or later added it.

Quote from: Henrik at Aug 15, 2012, 08:55 AM

As a more personal note, I'd be happy if all the addons in the "Package Management" has links to the documentation for the specific addon, and that these will open in a new window!

I second this, as loudly as I can. One frustrating aspect of links within the MODX manager is the fact that they open in the same tab, effectively eliminating your manager view just to take a peek at a package's information. If you're browsing through the repository and take yourself to another page, using back in the browser sends you back to package management rather than the repository. I feel that all links should open in a new tab without the need for a browser plugin.

@smashingred Jay, another thing I wanted to mention is that the options in the left sidebar for logged-in users looking at their own extras are not as clear as they might be (add new version, update version, update package).

I'm never absolutely sure what each one does. In some sense, all three apply when I submit a new package version and there is some overlap in what you can do after making each choice. Maybe it's just me, but even after being through there many dozens of times, I still find them confusing.


------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using.
MODX info for everyone: http://bobsguides.com/modx.html

These are all some sensible and positive improvements to the Extras and Package Management that would add a lot of value for users. I will distill them into a clear list of improvements we can make in the coming months.

I'd like to ask everyone for their opinion in terms of urgency and priorities compared to other improvements needed in the software, the launch of cloud, improvement of the documentation, usability and function of the forums and learning materials.

POLL in the light of the previously mentioned areas, on a scale of 1 to 10 how important are these changes to the Extras you you? 1 being least important to you 10 being critically important?

Jay