A formal RFC process for Joomla!

[dukeofgaming]

Hi to all,

I am summarizing a part of what happened at the "Nooku framework integration for J! 1.7" discussion regarding the need for a formal RFC process that could help us advance in shaping recurring feature requests and ideas. I'd really recommend all to read the original messages at following url, as they address the main intentions of this thread:

http://groups.google.com/group/joomla-dev-cms/browse_thread/thread/a477a550bb051f29/30c8fdf45ba1289c?hl=en-GB&

The main idea is that any seriously taken proposed feature should have a case made, so that our core devs can just say "it makes sense, we can include it at certain point" or "the idea needs more work" and even "here are our ideas/work/intentions so far on the subject", instead of debating others' absolutes at the discussion groups (for example with the jQuery topic and now the Nooku framework one).  

This formal process would be targeted at anybody that can make meaninful contributions, from use case scenarios and UI mockups to detailed architectural designs; then after something is accepted we can code with the aim of adding to Joomla in a *sustainable* fashion.

So, the purpose of this thread is to move forward from the last topic taking the following into consideration:

• We could really use a process where we can mature and evolve "crazy" ideas discussed in the Google Groups to workable solutions so that our core devs can give their insights to them once they are drama free.
  
• Two good examples of how this process would be documented/executed are the official PHP RFCs (http://wiki.php.net/rfc/traits) and Python's PEPs (http://www.python.org/dev/peps/pep-0001/).
• We would use the wiki to document the RFCs where the relevant discussions are linked and people can see/contribute to the process according to a set of guidelines.
• Each case would turn into concrete, well detailed and workable ideas that the community can constantly enrich, not wishlists.
• These approaches would help put in perspective complex propositions that have been addressed in the past, such as:
• Javascript library agnosticity / OO jQuery integration with Mootools
• Integrating Doctrine or implementing an ORM library from scratch for Joomla
• A CCK 
• A package manager ala Debian (mentioned by Sam)
• Native content translations for Joomla (like Joomfish or Nooku)
• Template framework enhancements (taking the Gantry framework by Rocket Theme)
• Framework feature additions inspired on other frameworks, such as the Nooku framework, Kohana, Symfony, Yii, etc
• And perhaps even non-functional features or changes regarding such as code structure, database, conventions.
• As Niels pointed out in the other thread "The state and maturity of the proposals would automagically make up a reliable roadmap". This would help the community contribute to the main roadmap.
• Amy proposed that additions such as the ones listed could be worked on as extensions (including framework additions). Quoting her: "Maybe the process would always call for first use as an extension and then possible inclusion as core if successful and broadly needed". My thought on the subject is that the extension could be labeled at JED as a "Core Candidate" so that people would know where to contribute.

Carrying on, the general process would be:

Discussion -> Crazy Idea -> Draft -> Accepted Feature -> Community Extension and/or Roadmap addition -> Core Candidate -> Core Inclusion

• First, a feasible idea gets discussed in the Google Groups
• A crazy idea with a clear benefit for the Joomla community arises.
• A draft is generated/refined.
• Once the draft is mature and complete enough (determined by guidelines to be yet proposed), the core team can then review the draft and provide insight to it.
• If the draft gets accepted then the feature could get included to the roadmap (as Niels pointed out in the other thread).
• People can start to implement the feature if the core team can't because of their current workload or the current roadmap. 
• Once it is stable enough (in both form and function) it can finally make it into Joomla

The most important goals regarding this process, as I see it, would be:

• Having a path for meaningful contributions to the roadmap and Joomla itself.
• Getting ideas and code contributions mature and well coded enough so that the core team can just cherry-pick, test and integrate them most of the time.

Finally, regarding Louis' questions:

"What of what you are proposing do you see as being needed from leadership or project resources?" 

• Once the process is determined, I think an effort should be done to make the process noticeable and an active part of Joomla development workflow and philosophy.
• Perhaps an additional Google Group, targeted only to RFC discussions. This group would be for a specific audience, and could need specific rules to discuss RFCs. Chances are I'm wrong and this is not needed at all.
• Perhaps an additional RFC tracker type, being the trackers, future Joomla versions (http://joomlacode.org/gf/project/joomla/tracker/). This tracker would not be aimed at coding but could help build the roadmap in an active fashion.
• Integrating this process to GSoC, meaning, having existing project ideas become RFCs and helping RFCs becoming GSoC projects
• Attention from the documentation team.
• Attention from the development team.
• An open mind =). The way I see it this would serve the purpose of facilitating the contribution process and giving it additional transparency, not adding extra burden to the Joomla team. 

"What do you envision as next steps?"

• First of all, I think we should discuss what the process should look like. I think we could start from the outline I summarized (Crazy Idea -> Draft -> ...)
• Then, we should consider the guidelines, these include: code and modelling conventions, tools, workflows, principles, etc. ...and documentation formats (look at the the PHP and Python examples).
• Then I think we should make the wiki entry and rescue everything agreed.
• Then... we could start to address some of the complex propositions as en experiment just to illustrate the process, but with the intention of carrying on. We could address the following topics that have been addressed in the past and that have some concrete ideas already put in place:
  
  "jQuery as a replacement for Mootools", superceded perhaps by "Javascript library agnosticity and conlfict handling" (ideas were previously formulated that we could integrate)
  "Nooku framework integration" (that I think should be superceded by a draft called "Lessons from Nooku")
  "Doctrine Integration", probably superceded by "An ORM Library implementation for Joomla"

Comments?.

Regards,

David

[brian teeman]

This sounds like an excellent and well thought out plan of action.

My one and only concern is that there is no roadmap for Joomla, no
published plan on where Joomla is going or the targeted users or
uses.

Surely this would need to be defined first to enable the decision
makers to decide if the RFC is appropriate for inclusion based on its
compatibility with the roadmap and not just on the quality of the code
itself

On Apr 15, 5:14 am, dukeofgaming <dukeofgam...@gmail.com> wrote:

> The most important goals regarding this process, as I see it, would be:
>

>    - Having a path for meaningful contributions to the roadmap and Joomla
>    itself.

[Andrew Eddie]

I think the idea of a roadmap is a chicken and egg scenario. You want
to know what the roadmap is before accepting RFC's, yet RFC's are a
way to set the roadmap.

My biggest hassle with 1.6 has been the inconsistency of effort. We
have very few people actually putting in consistent hours, and there
are an awful lot from Gunnadoo sporting the latest Roundtoit (for
those not familiar with the slang, many have said they'd do things and
just disappeared). So, while I'm right behind this sort of system (we
did it for 1.5 way back when, albeit less formally), the problem comes
after you've made the decision when someone actually has to do the
work.

I'm certainly happy to see some fruit from this kind of discussion,
but given the number of things we've tried in the past, I'd rather err
on approving working prototypes and have a mechanism for setting a
vision or theme for each release - something a little more organic
(only because we haven't tried that one yet, hehe).

Whatever the case, I'd like to see the wider community stepping up to
the plate more in deciding what they want to be working on, but be
equally supportive of assisting with the execution. Anything that can
help achieve both aspects will be a blessing. I was introduced to
IBM's Ideastorm site last year and thought that was an interesting way
of handling it.

Those are my thoughts anyway.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

> --
> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
> To post to this group, send an email to joomla-...@googlegroups.com.
> To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
>

[brian teeman]

On Apr 15, 8:38 am, Andrew Eddie <mambob...@gmail.com> wrote:
> I think the idea of a roadmap is a chicken and egg scenario.  You want
> to know what the roadmap is before accepting RFC's, yet RFC's are a
> way to set the roadmap.
>

Sorry but I disagree. RFC are a way to satisfy the aims of the
Roadmap.

If Joomla is to be just a technical playground then its fine to be led
by RFC but it's not a playground its a serious CMS and the RFC should
be selected based on their compatibility with satisfying the general
aims of the roadmap.

[Andrew Eddie]

How do you set the roadmap?

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[brian teeman]

On Apr 15, 8:46 am, Andrew Eddie <mambob...@gmail.com> wrote:
> How do you set the roadmap?
>

Firstly I would define the targeted users for Joomla. eg Is it
intended to be suitable for every web site that might exist or is it
targeted at specific marketplaces.

When you have done that you can start to define the features required
to satisfy that goal and RFC can be matched against that to see if
they are appropriate.

For example if a targeted userbase is for corporate intranets then an
RFC for complete Active Directory support would be appropriate and
worth investing the time

But if the targeted userbase was not for corporate intranets then an
RFC for DB agnosticism would not be appropriate.

By defining a roadmap you are then able to concentrate skills, talent
and time to satisfy the needs of that roadmap.

[Andrew Eddie]

Let me rephrase, who is responsible for, and what is the process for
"defining" the roadmap?

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[Andrew Eddie]

For reference, the same "kind of" thing is being discussed here:

http://forum.joomla.org/viewtopic.php?f=571&t=507284 (thanks Jacques)

There's a good reference to what KDE does here:
http://forum.kde.org/brainstorm.php#cat95

IBM's version is here:
http://www.ideastorm.com/

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[brian teeman]

On Apr 15, 10:15 am, Andrew Eddie <mambob...@gmail.com> wrote:
> Let me rephrase, who is responsible for, and what is the process for
> "defining" the roadmap?
>

Well I'd like to think that the project leadership would be able to
define that

[Andrew Eddie]

Ok, thanks for the clarification (and confidence, genuinely
appreciated). I was assuming that the community would want to have a
hand in defining the roadmap itself and I then assumed that an RFC
process 'could' be used to facilitate that. At any rate, if it was up
to me, I'd be wanting for the community to share in the process of
defining a "direction" (be that a surveyors traverse or simply a
compass heading). Maybe that's via an idea forum, maybe a dev
conference - dunno.

But yes, after that, the RFC's/ideas can be rightly judged according
to how well they fit the goals for the the release, Joomla, or
whatever.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[Shyam Verma]

We can start using uservoice.com, that way we can track at least idea's popularity.

[Amy Stephen]

David -

I'm resting a lot of hope on your idea. We are in a terrible rut. This
method we are using of proposing "great ideas" in the forum is not
working. If the idea gets any attention, it is generally negative
attention and the proposing group and the project argue about why it
should or should not be done, the discussion never even addresses
technical merit or shortcomings, and it's not infrequent that it turns
unfriendly.

If a person is not well known in our community, their ideas tend to be
overlooked. I have no doubt we are losing a lot of talent - I know
this to be the case. Low success rates of community driven efforts
have caused some in the project to give up on believing that community
efforts will ever be successful. Those who start and do not finish
have sometimes indicated a lack necessary feedback, answers to
questions, encouragement, or information has blocked their success and
they finally gave up. I've been around long enough and watch closely
enough that I know this is true and I could provide links to prove it.

We hear how community doesn't participate. We hear how project will
not allow them too. And this just repeats, over and over, and as it
does, the frustration on both sides mount. The net results is we just
are not advancing our code base like we should be if we weren't firing
blanks.

I was and am encouraged to hear you come forward with ideas on how we
might formalize this process so that we better traction in this area.

I think it is very important that whatever you propose be visible and
open to everyone.

Expectations must be crystal clear. I recommend a monthly review
process by the Development Working Group Coordinators who would review
the status of each RFC which has progressed since the last review and
provide feedback on next steps for participants.

For the review, it would be good if the project provided both a status
(ex. need more information, not accepted for core, develop and offer
as extension, under consideration by Development Working Group
Coordinators, added to the roadmap). Also, providing a narrative
explaining a bit more would be good. (For example, "develop and offer
as extension" with comments that the idea has merit and will be
considered after six months of use by the community.)

I recommend that this review be done by the Development Working Group
Leaders, themselves, if at all possible.

It also needs to be clear to community that this resource is primarily
for us to work together on solving our problems with others who are
also interested in doing so. That is the PRIMARY purpose. The
secondary goal would be the inclusion in core. Your diagram that shows
the progress of the idea along a continuum helps make that clear - and
having a visual of that nature on the form - with a "Your idea is
here" kind of graphic will also help drive that home.

This needs to be a No "No" zone. We have to move away from the project
being forced into an uncomfortable position of saying "No" - to an
approach where we focus on providing a place and a process for people
with the same ideas can find one another and help each other develop
solutions. This has to be about empowering community and getting out
of their way - not about coming to the project and hoping they hear us
and do what we want.

In order for this to work, people will have to see it's working.
Having automated status reports would be great. 15 new RFCs created,
45 people actively working on RFC's during the last month; 4 new
extensions introduced as prove of concepts - and here they are - and
here's who did it, and so on. The more visible the output of this
system the more encouraged people will be to participate, and so on.

Again - thanks - I'm here for you, David. I've got years of data
warehousing experience and report development, etc., so, I want to
help you with this - it is what we need and I do want to see us being
to get better traction and bring down the drama a great deal. This
idea has merit. Feel free to assign me work.

Amy

[dukeofgaming]

@Shyam

Using Uservoice is an excelent idea. I have been using it to give feedback to two particular projects: Cacoo and Mendeley. And I can tell so far it is a tool that helps reflect the community's sentiments and desires. We should be careful when adding another way of communication for the community because it is another place to moderate and it might add confusion... but for the case of Uservoice, I think it would fit in nicely, because of what Andrew said:

At any rate, if it was up

to me, I'd be wanting for the community to share in the process of

defining a "direction" (be that a surveyors traverse or simply a

compass heading).  Maybe that's via an idea forum, maybe a dev

conference - dunno.

Uservoice could be a tiny version of the RFC process, since recurrent ideas are easy to find, vote, comment and therefore contribute to; debates can instantly be redirected to the Google Groups, and ideas to the RFC protocol. For those not familiar with Uservoice, take a look at this:

http://feedback.mendeley.com/forums/4941-mendeley-feedback?lang=en&utm_campaign=Widgets&utm_content=tab-widget&utm_medium=widget&utm_source=mendeley.uservoice.com

After this process is laid out and its about to be communicated to the community, maybe we should look for a way of making the purpose of this really distinguishing, since the community might interpret it as "OMG, look!, they are opening the Roadmap to us!!!" *Joomlafolk stampede*, the technical nature is enough to discourage those who want to treat it as a wishlist, and Uservoice would be a wishlist that helps the RFC process not to be treated as such, remembering what Sam said happened last time.

@Brien & Andrew

Even while the J! 1.6 roadmap is something we need to consider right away, my belief is that we should do it after we define the process. The RFC process would undoubtedly contribute to the roadmap, but I don't think we can know how until we actually have the process. I have put the item on a draft action plan in the wiki: http://docs.joomla.org/Rfc#Draft_Action_Plan

@Andrew 

I've seen help being called for for Joomla 1.6, and yet as you said, the problem lies in that it somehow when it comes the time to work, motivation vanishes. I can now clearly see the benefit of what I'm about to propose, it might scare some of you, even disturb you and be referred to as something unnecessary and problematic, however, Amy also just said something that hit me: 

"The net results is we just are not advancing our code base like we should be if we weren't firing blanks." and "I think it is very important that whatever you propose be visible and open to everyone."

So here goes: 

I think Joomla could really really... really use switching to a distributed SCM tool such as mercurial.

My intention of suggesting this (actually for second time) is that I think there should be an owner/responsible for each RFC. This owner, instead of having him/her put a link to a patch (which probably wont), can start a repository in a matter of seconds (at Bitbucket or Github, for example) and put the link to it, even if its empty. 

The difference of having mercurial instead of subversion is that people can start committing to another live, published repository and propagate the effort. Also, the core team would *now* have the *ability* of reviewing/contributing *back to them*. Code contributions automagically turn into a social experience and the coding process now becomes bidirectional (core team <-> us mortals), such is the nature of a DVCS (or distributed SCM).

I understand the implications and I'm aware it wouldn't be a trivial switch. I also know some have more than enough with Subversion, but I want to state clearly that with a distributed VCS tools are not a trend, nor a toy, they are a valuable medium for coding contributions/workflows that works better for an open source project instead of the centralized and bureaucratic thing that Subversion is, specially for big projects. 

I don't want to deviate the topic, so sorry if I vered off. For the later consideration of this I'll provide the following links:

• "Tech Talk: Linus Torvalds on git" http://www.youtube.com/watch?v=4XpnKHJAok8
• "Distributed Version Control is here to stay, baby" http://www.joelonsoftware.com/items/2010/03/17.html
• "Subversion Re-Education" http://hginit.com/00.html.
• An excellent way to get into the "why" and "how" of DVCSs and Mercurial http://hginit.com/
• Google's Reasons for Mercurial, including a large SVN userbase and good Windows support (git is difficult to setup with windows): http://googlecode.blogspot.com/2009/04/mercurial-support-for-project-hosting.html 

So yeah, I think a DVCS would help a lot to increase the coding effort and help a willing RFC responsible stand out and get help. I know we have GForge as a place for contributions, but this is the kind of wave everybody is surfing already.

@Amy

I think a monthly review of RFCs is a very nice idea, but I'd suggest it would a monthly review of only the mature ones. Smaller and relatively new ones would just need a quick insight to it, perhaps on demand, as in the contributor(s) saying: 

"Can we please have someone from the team look at this and tell us if we should move forward on it?"

I'm suggesting this because you said:

"Those who start and do not finish have sometimes indicated a lack necessary feedback, answers to questions, encouragement, or information has blocked their success and they finally gave up."

And that is really true, I can tell. Perhaps they didn't even give up, they just forgot. Now, don't get me wrong with what I'm about to say but, I think an RFC should be "rejected" as soon as possible, why?, to straighten the path of the idea so that effort is not invested in vane, leading to frustration. 

For example, if I spent a whole afternoon providing ideas on how to integrate Doctrine into Joomla (*cries*) and Joomla has the philosophy of not depending on external libraries, and I'm not aware of this, and my idea gets people excited with Doctrine, there could be a lot of frustration/anger.

Even small RFCs should be mature enough to be well shaped, workable and drama free, so it shouldn't be that demanding for the team to give a quick insight to small and new RFCs. Also, you said: 

"For the review, it would be good if the project provided both a status (ex. need more information, not accepted for core, develop and offer as extension, under consideration by Development Working Group Coordinators, added to the roadmap). Also, providing a narrative explaining a bit more would be good. (For example, "develop and offer as extension" with comments that the idea has merit and will be considered after six months of use by the community.)"

I think this is an excellent approach, the "status" of the RFC should be as fresh as possible, and IMO, this would be a requirement for small/new RFCs. The "status" and its "reason" would allow the community to keep working, if its a new/small one this would give it momentum, I'm sure of it.

Finally, regarding what you said here:

"The secondary goal would be the inclusion in core. Your diagram that shows the progress of the idea along a continuum helps make that clear - and having a visual of that nature on the form - with a "Your idea is here" kind of graphic will also help drive that home."

Now, I think an RFC tracker for the core project at GForge would make even more sense. This could be how the core team decides what ideas to review monthly and which ones need their initial dose of attention.

@all

I think its really important to start adding to the wiki page (http://docs.joomla.org/Rfc) so that this starts to actually shape up.

Regards,

David

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.

[Mark Dexter]

I really like the idea of something like Uservoice, especially for identifying smaller changes. Obviously, we have to manage expectations around this and make it clear that "code speaks louder than words".  But it would be very helpful to know what improvements are in popular demand, even if we know we won't be able to do all of them.

My experience over many years is that often there are a number of small, easy to implement changes that can make a large improvement for users. These can be win-win situations.

One thing developers need to keep in mind is that users often know more about the good, bad, and ugly of a program than the developer. I like to compare it to a house. Yes, the architect designed the house, and the builder built it, but the person who has lived in the house knows it much, much better than the architect or the builder. The same thing applies to software users versus the software developers.

Mark

[Louis Landry]

I would echo what Mark said there regarding the process and managing expectations.

Regarding roadmap/RFC I would say that to me it makes no sense to limit ideas to what a small group of people define as the path moving forward... especially in a process where by the very purpose is exploring new ideas.  One of the great benefits of being an open source project like we are is our ability to adjust our course if a good idea comes up.

I think there can certainly be a system setup where by for a given release (say 1.7) an abstract vision is put forth as what we want to achieve there, and then an RFC-esque process is utilized for defining some goals for that release, but I don't see that as having the same purpose as what is being proposed here... maybe i'm mistaken.

Either way, lets not put limitations on what this is quite yet.

@David, I really like the approach.  I don't envision any issues with what you are asking of the leadership/project resources and would be happy to help you get setup with whatever you need there.  If you want to shoot me a personal email I can start that process for you.

- Louis

Development Coordinator
Joomla! ... because open source matters.
http://www.joomla.org

[dukeofgaming]

@Louis & Mark

That exactly would achieve Uservoice. I've seen it in action, specially on Mendeley. User's needs keep bubbling up until they become evident to all. Then the team can choose by size. 

The awesome thing about Uservoice is that votes are limited, so users tend to vote higher for what they need and see doable and less for what they want. It's unlikely there will be technical lots of requests such as framework additions, so again, users focus on what they need.

@Louis

Thanks a lot, I'll look at what could be done first and get back to you later today.

@all

Here is what I picture as the evil master plan https://cacoo.com/diagrams/QGOVgMrfNNgaTvGf, integrating contributions to the process. The diagram is open so anyone can edit it and I'm also attaching it here. 

As you can see, the RFC process would be executed at the upper half, while on both the accepted RFCs and Joomla itself would benefit from a joint dynamic on the lower half.

As I mentioned to Andrew, I think that a distributed VCS + a social coding site (or the DVCS alone)  would play a major role here, specially:

• In the "Extension WG Team Assembly" process. The social coding site facilitates communication with the extension team, and well, if you haven't seen it, people tend to fork projects in these sites just for fun.
• The Delay=Yes -> RoadmapReschedule=No scenario, following a *delegation* of the feature/extension to the community.. or the core devs. 

Delegating back and forth is trivial with a distributed SCM tool such as git & Mercurial, because forking and then *merging* is trivial too (http://hginit.com/00.html <-here is why).

The points of entry to contribute would be on the RFC and RFC discussions. The point of entry to coding would be the social coding. Motivation would come from seeing the working solution marked at JED as "Core Candidate" and pointing people to the right places to contribute, from the groups and uservoice.

As I'd like to see it:

1. RFCs as entry points for idea contributions
2. DVCS + Social Coding as entry points for code contributions (on both Joomla and "Community Extensions")
3. Profit =)

Comments?.

Regards,

David

[Andrew Eddie]

Comment: I really like that David. Make it happen.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[dukeofgaming]

@Andrew

Thanks for your comment =)

@all

I've just finished updating the wiki page at http://docs.joomla.org/Rfc

I'd love to hear some feedback regarding the action plan in general, the format (item 1.2) and the process (item 1.1). 

For the format, I'm a little worried the format might be complex, but I'm taking into account that:

• It should be easy to review for the core team. Do you think it is the case?
• It should be able to scale to a GSoC-like process or GSoC itself. Do you think it is the case?

For the process:

• What do you think of the role of JED?
• What do you think of the role of a distributed SCM?

What do you think?.

Regards,

David

[dukeofgaming]

Hello again,

Well, it ends up Joomla already had uservoice, and I am wondering on what would be the next step with it? (apart from cleaning it up http://joomla.uservoice.com/).

I am thinking that the uservoice forums should mirror the google groups (at least CMS and Framework), what other forums (I see them more as sections) would you suggest?.

Regards,

David

[Omar Ramos]

There's an awesome newer extension on the JED that emulates UserVoice's Interface:
http://extensions.joomla.org/extensions/contacts-and-feedback/testimonials-a-suggestions/10283

I feel like it would be a great choice for implementing a UserVoice-like suggestions system.

-Omar

[Matt Thomas]

++

I agree that a Joomla! native extension should be used rather than an external service.

Best,

Matt

On Thu, Apr 22, 2010 at 2:04 PM, Omar Ramos <orw...@gmail.com> wrote:

There's an awesome newer extension on the JED that emulates UserVoice's Interface:
http://extensions.joomla.org/extensions/contacts-and-feedback/testimonials-a-suggestions/10283

I feel like it would be a great choice for implementing a UserVoice-like suggestions system.

-Omar

[Niels Braczek]

Matt Thomas schrieb:

> ++
>
> I agree that a Joomla! native extension should be used rather than an
> external service.

+1. Generally, Joomla should show its potential by not using external
services (as far as possible).

Niels

--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

[Andrew Eddie]

Something I've been thinking about is ideas that kind find legs, but
are not intended to be part of the core, but that regular contributors
actually maintain in a sub-official way. Let me share an example. I
have an extension called Engineer which is a type of extension
builder. There are a few people around doing this and I've spoken to
at least one and we thought it might be good to collaborate. This
isn't something that should go in the core, but it may become a highly
regarded extension if enough developers decide to pitch in.

Now, I see no reason why this couldn't theoretically start out as an
RFC, but it's never going to get PLT approval to be included in the
core distribution. So, for something like this, is there an
alternative "off ramp" to a slightly different process that helps
other developers find cool toys other people are working on. In fact,
this could be part of the initial process - a small team might just
want to play with something, advertise that fact, and wait until it's
mature to send it to the PLT for the appropriate nod.

I would see these things as being developed organically in sandpits or
incubators in the new subversion repo, not necessarily being done on
JoomlaCode. I guess in a sense I'm talking about registering
"community development projects" that are perpetually maintained by
the active development community at the time, but keep them within the
mix of this RFC "thing" so that other people know that they exist. As
the system develops we could eventually add issue trackers and such
(and that in itself could be a community infrastructure project along
with the RFC system).

Does that make sense?

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[Mark Dexter]

I don't know if this is exactly the same, but I think it's similar. I've been thinking a lot of the concept (which I'm sure is not new) of "official" or "project supported" extensions.

As you say, there are extensions that are valuable to the Joomla! ecosystem that don't belong in core. However, there are huge advantages to users to having a family of official extensions. Here are the ones I can think of.

1. First place to look for solutions.
2. Reliable quality.
3. Support on J! forums (maybe a separate forum for these?)
4. Bug fixes by JBS (maybe a separate JBS group?)
5. Security fixes by JSST?

From the project pov, there are also advantages to this approach.

1. Extensions don't have to be tied to J! development cycle, so students (or others) could contribute work based on their schedule (GSOC, JSOP, etc.) and new versions/enhancements released when ready.
2. Devs of quality extensions could offer their code and convert them to J! extensions and transition support and maintenance to official J! groups.

This is just an idea at this point. There are major questions to be discussed, such as whether we have the resources to support these.

Anyway, wanted to throw it out there. Thanks. Mark

[Hannes Papenberg]

I like the idea. When I'm thinking about this, I see Joomla somewhat
like the Mozialla foundation. We have a bunch of projects that are
supported and run by the "foundation"/Joomla project and when installing
a Joomla, you can have either a standard installation or you can install
more or less extensions (plugins, components, modules, framework libraries)

Hannes

> <louis....@joomla.org <mailto:louis....@joomla.org>>

> <dexter...@gmail.com <mailto:dexter...@gmail.com>>

> <dukeof...@gmail.com <mailto:dukeof...@gmail.com>>

> <amyst...@gmail.com <mailto:amyst...@gmail.com>>

> <mailto:joomla-...@googlegroups.com>.

> >> >>>>> To unsubscribe from this group, send email to
> >> >>>>> joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

> >> >>>>> For more options, visit this group at
> >> >>>>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> >> >>>>>
> >> >>>>
> >> >>>> --
> >> >>>> You received this message because you are subscribed to
> the Google
> >> >>>> Groups "Joomla! CMS Development" group.
> >> >>>> To post to this group, send an email to
> >> >>>> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

> >> >>>> To unsubscribe from this group, send email to
> >> >>>> joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

> >> >>>> For more options, visit this group at
> >> >>>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> >> >>>
> >> >>> --
> >> >>> You received this message because you are subscribed to the
> Google
> >> >>> Groups
> >> >>> "Joomla! CMS Development" group.
> >> >>> To post to this group, send an email to
> >> >>> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

> >> >>> To unsubscribe from this group, send email to
> >> >>> joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

> >> >>> For more options, visit this group at
> >> >>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Development Coordinator
> >> >> Joomla! ... because open source matters.
> >> >> http://www.joomla.org
> >> >>
> >> >> --
> >> >> You received this message because you are subscribed to the
> Google
> >> >> Groups
> >> >> "Joomla! CMS Development" group.
> >> >> To post to this group, send an email to
> >> >> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

> >> >> To unsubscribe from this group, send email to
> >> >> joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

> >> >> For more options, visit this group at
> >> >> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> >> >
> >> > --
> >> > You received this message because you are subscribed to the
> Google
> >> > Groups
> >> > "Joomla! CMS Development" group.
> >> > To post to this group, send an email to
> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

> >> > To unsubscribe from this group, send email to
> >> > joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

> >> > For more options, visit this group at
> >> > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> >> >
> >>
> >> --
> >> You received this message because you are subscribed to the
> Google Groups
> >> "Joomla! CMS Development" group.
> >> To post to this group, send an email to
> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

> >> To unsubscribe from this group, send email to
> >> joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

> >> For more options, visit this group at
> >> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> >>
> >
> > --
> > You received this message because you are subscribed to the
> Google Groups
> > "Joomla! CMS Development" group.
> > To post to this group, send an email to
> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

> > To unsubscribe from this group, send email to
> > joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

> > For more options, visit this group at
> > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To post to this group, send an email to
> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

> To unsubscribe from this group, send email to
> joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

[dukeofgaming]

@Andrew

It does, a lot. 

@all

Some days ago I had some words with Louis and reached the same notion: not everything should be in core, perhaps not even core extensions themselves.

Here is an important bit I commented Louis when he had just mentioned some outlooks about the "core candidate" initiative regarding keeping Joomla simple enough (something already discussed by others), remembering what Amy said about sustainability here is what I said (note: while writing this I've received the discussion update and I see now that it seems to be the general desire of some):

Sam mentioned an idea of a package manager ala Debian, and I just remembered Drupal uses "installation profiles" to include stuff out of the box without needing to cram it into core, so I think something like that as a single solution would be the panacea to this situation. I'll ellaborate some more about this:

If most/all of the core components/extensions/plugins could be decoupled from Joomla itself but still known that they are maintained by the core team, labeled somehow and recommended at installation, a modular web installer would emerge as a practical application of this [I just got the shivers], and at the same time, being Joomla in pieces and at the JED, the officially maintained extensions would get extra attention and even more contribution... and even perhaps clustering people into teams either to contribute to them or match/complement them, leading to the same objective as before and even better.

I could see Joomla 1.7 taking this approach of having its extensions at JED and having a web installer. I'm willing to help code this and make it happen. Perhaps installation profiles could make it to J! 1.8, and a way more mature package manager to J! 1.9 or even 2.0.

Something I have observed that hurts open source is bureaucracy. Having an approval process, enforcing logistics, moderating, etc etc. is not something really targeted to communities but to the community maintainers to deal with the community... its not people oriented, not natural, not organic, and could add even heavier burden to the maintainers.

Now, as I see it, there are two kinds of contributions for Joomla (regardless of their nature, i.e. bug, feature, security, etc.), and those are framework contributions and extension contributions. The only thing that actually would need approval would be framework modifications, because they affect everyone, but extensions... I mean, that's the whole point to them, being modular in nature.

A step towards having Joomla distributions, in a more technical sense, would be defining a way of handling dependencies. I could help make this happen.

If we had a light Joomla distribution that would only have the web installer, then there could be some kind of ballot screen where you could choose from official extensions and extensions at the JED... where official extensions are already at the JED but tagged in a special way. 

That being said, for this to work properly, I think the extension rating system should implement some additional tags/mechanisms. I think -as Mark suggested- "Project Supported" would be an excellent tag, "Officially Supported" IMHO makes it feel bureaucratic, "Core Supported" perhaps would be the middle ground.

How is this relevant to the RFC process?. 

I think each extension should have more than one representative, I don't know if this is technically possible (without hacking) but if the JED had the way of changing the "Developer" field and having instead something like "Main Developer" or "Lead Developer", and additionally, "Active Developers" or "Team Members" or "Maintainers" the JED would start being compatible with what I previously laid out in the wiki entry (the contribution workflow part of the diagram, part of the RFC format/formality).

Okay, now, each extension has a team, a responsible. Extensions become more democratic and the core extensions now could have the benefit of getting additional and individual attention instead of having the "default stuff" notion. 

I think the following would be a scenario of what I think would actually happen. 

"I want to make a banner extension that can handle flash... wait, why don't I just contribute to the existing one?" (Contributions would now mean well shaped ideas, and not only code).

"Well... yes I'm a developer, but where do I start?, it would just be easier to attend my current need and share it, I don't want it to be subject to approval, its burdensome!, I-just-want-to-share-it". (What happens here?, the developer wants to touch the core extension but does not want to loose time with a nebulous process.

*Enlightment*

"Oh!, I can fork the extension, publish it somewhere modified and tell these other guys interested to take a look at it". (The fork could be published at Joomlacode, Google Code, a personal SVN server, or their bitbucket/github accounts).

"How do I contact them?... oh there they are, listed at JED".

"Well, they told me they weren't that interested at the moment *sigh*, but referred me to this wiki page with a bunch of guys proposing this..."

"Hey!, it looks like what I'm doing, it needs some tweaking to what I did to match their idea, but they are missing some parts of the idea I already implemented... I'll contact them". (What Joe perhaps hasn't realized here, is that he is already contributing to the RFC process AND participating in the contribution workflow).

"They actually liked it... they asked me to be in the extension team!... wow, I'm important".

Summing it up, Joe here had a safe route already laid out ahead of him so he could contribute, if not in code, at least in ideas, and he had several points of access to contributions. If however he saw what he meant to do already done, he could just have ended up voting it up in uservoice.

The *Enlightment* part is the RFC process, an important part of a single, digestible, approachable and visible initiative of how to contribute without obstacles.

Comments?.

Regards,

David

[Matt Thomas]

This is a fantastic idea. From a fledgling developer point of view, this could really help new projects get off the ground as well as provide a vehicle for single developers find like-minded individuals to work with. Just to play the Devil's advocate, would this be for purely non-commercial GPL projects? If so, how would it be handled if a project where ported to a commercial project?

Matt

Matt Thomas
Founder - betweenbrain
web • print • identity • creative
www.betweenbrain.com

betweenbrain at The Joomla! Resources Directory™ - http://betweenbra.in/resources

[dukeofgaming]

I think there would have to be an unanimous agreement between the members of the extension team. So, anyone that makes a substantial contribution && is considered in the active team (and therefore listed as member of the team) should have a voice, me thinks.

Personally and as a user, I've always seen this kind of switch as a betrayal (*remembers of IPB*), but the owners of the code should always have that right. Of course, project supported extensions (i.e. core) should make a commitment that this won't happen, or they'll have to eat a bucket of slugs, or something more legal and relevant. 

So: a project supported extension is supported under the agreement that wont be ported to a commercial one, regular extensions have the freedom to do so, commercial ones stay as such or can be ported back of course. That looks right?.

Now, perhaps the web installer would only recommend the project supported and the regular ones for direct installation, and the commercial ones maybe if they are relevant enough (ALTHOUGH I REALLY WOULDN'T LIKE THIS TO TURN INTO AN *APP STORE*, yeah, that).

Regards,

David

[dukeofgaming]

P.S. I meant that commercial ones were to be *recommended only* if they were relevant at JED (editor's pick, or very popular).