Content publishing bug

[Justin Seliga]

I raised this issue on Github, and after more thought it seems that this isn't just a missing feature, it's a bug. Permissions are a core feature and the implementation of that feature in another core component should at the very least be consistent.

The expected permissions for Author, Editor, and Publisher only partially adheres to the logical understanding of these roles.

That is to say that once an article is created, changes made by an Author to an already published article should not be reflected in the data stored in #_content. Likewise for Editors. However, this is not the case, and Authors/Editors are effectively granted publish permissions on existing  articles.

As a proposal, though it's not as feature rich as a work flow manager, it seems like a reasonably achievable way to fix this bug. It needs to be scrutinized, but should be starting point for conversation.

Assumption

1. Authors

   • Can create new articles

   • Can edit their own articles

     • When they save, state is automatically set to "Awaiting Review"

2. Editors

   • Can edit articles

     • Can save with states:

       • "Awaiting Review"

       • "Approved"

1. Publishers

   1. Can edit all articles

      • Can save with any state

Concept (Back-End)

• The logic for displaying the list of articles a user can see doesn't need to change

  • Bring in another column "workflow"

    • Set this value as the state of the most recent version

• An artificial work-flow is already built-in by the nature of how filters work.

  • Are you an Editor?

    • Change the new "Workflow" filter to "Awaiting Review"

  • Are you a Publisher?

    • Change the new "Workflow" filter to "Approved"

• The most significant change is the data loaded into the edit form (front-end & back-end)

  • Instead of loading from #__content, load the most recent version from #__ucm_history

  • The list of states will be populated based on user's ACL of that item / item type / category according the logic listed in the Assumption section above.

Issues

• This is business logic, though I don't see an easy way to easily prevent a row from being updated in #__content (for everyone that doesn't have publisher permissions) while still inserting into #__ucm_history without putting this check in JTableContent::store or JTable::store.
  

[brian teeman]

On Tuesday, 9 June 2015 18:06:14 UTC+1, Justin Seliga wrote:

I raised this issue on Github, and after more thought it seems that this isn't just a missing feature, it's a bug. Permissions are a core feature and the implementation of that feature in another core component should at the very least be consistent.

Can you point out where it works as you have described? You are correct it should be  consistent

[Justin Seliga]

Scenario 1

1. Author creates Article 1 (automatically saved with state Unpublished).
2. Publisher sets Article 1 status to Published.
3. Author/Editor edit Article 1
1. A new version is created and becomes the Published version. (unexpected / logically inconsistent)

Scenario 2

1. Author creates Article 2 (automatically saved with state Unpublished).
   
2. Author/Editor edits Article 2
1. A new version is created and stays Unpublished. (expected / logically consistent)

Two different outcomes when an Author/Editor edit an article. Only difference was the state of the article when they made the changes. Scenario 1 effectively ignores the role of Editor and Publisher.

For consistency the original version that was previously marked as published should remain the published one when an Author/Editor modify it until a user with Publish permissions marks a newer version as the Published one.

[Bakual]

The issue is that our versioning system basically only creates snapshots of the past and allows you to restore them again.
It doesn't create copies of the actual article.

So your proposal makes sense, and actually would also allow an autosave feature where the autosave is only done in a draft state, not touching the published version.

However as Roberto explained already on GitHub, this isn't something which can be done easy with the current way Joomla works. If someone is interested in doing it, go ahead. It would be a good feature I think. Just not the simplest one I fear.

[Justin Seliga]

The versioning system is a snapshot of the past and the present.

When an article is saved, a new version is also created in #_ucm_history (i.e. a row exists for the current version).

All I'm proposing is if a user is an Author or Editor and they make a change to an article, create the new row in #_ucm_history just like Joomla! already does, but don't update that article's row in #_content. Only a publisher should be able to set a different version as the active one.

[Sergio Manzi]

This doesn't seems much complicated (*at first sight*), but then what if you don't have history activated?

Another possibility would be to forbid Authors to edit published content (B/C hell?)

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

[Michael Babker]

Conceptually you're not off track.  But, implementing this is a major redesign in com_content (possibly the core Joomla API).  Doing this really gets into needing to support some form of workflow type API to enable users to define what the expected transitions are (i.e. if an article is published and user does not have X ACL permission and they make an edit, this should happen).  I also think the content history store is only a partial solution; if it isn't already (I haven't looked at what it can and cannot track lately), it needs to track the entire content record from the main article text to the params (as arguably those authors could change the extra images or links in an item too).

It really is a unique idea and would be a fun challenge to work through.  I'm just going to say though that I don't think it fits into our existing APIs though; maybe by way of plugins we can support workflow type decisions, but it really needs to be baked into core if we are going to go that route.  I've learned my lesson from trying to build major architecture in a plugin model (Smart Search), it's a major hack at best.

--

[Justin Seliga]

At the risk of playing a semantics game, I think it's absolutely critical to look at this as a bug instead of a feature.

As a product, specifically a Content Management System that provides ACL roles such as Author, Editor, Publisher, this is essentially the conversation Joomla! is having with it's users (site administrators):

Site Administrator

 

"I would like some users to be content contributors, but their content needs to be reviewed before being publish. Joomla! is this possible?"

Joomla!

 

"Absolutely, just put them in the Author user group! But there's a catch, those same users you don't want instantly making content available to your audience without review, we don't prevent them from making changes directly to articles that are already published."

This might sound drastic, but aren't we setting up a false expectations for our customers? I can't think of too many small to medium sized organizations where Joomla! isn't the perfect CMS for heavy content sites. But it absolutely fails in a decentralized content creation environment, where one body is responsible for reviewing and publishing but not producing content.

[Michael Babker]

It is a bug, I agree.  But the "right" fix from my perspective requires a major feature approach.  I don't see a way to slap a bandage on the existing structure that makes this workflow actually work.

The reason your unpublished scenario from above works is more by luck than intentional design.  Not being able to edit state leaves the state at the default unpublished, but the catch is just as you pointed out an edit can happen after publishing and there is no workflow backend to manage what happens.

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

--
- Michael

Please pardon any errors, this message was sent from my iPhone.

[brian teeman]

On Tuesday, 9 June 2015 23:04:31 UTC+1, Michael Babker wrote:

  I also think the content history store is only a partial solution; if it isn't already (I haven't looked at what it can and cannot track lately), it needs to track the entire content record from the main article text to the params (as arguably those authors could change the extra images or links in an item too).

It does track all those changes 

[Justin Seliga]

My idea was a quickly noted concept, it needs refined, and admittedly in the larger scope of work flow management is certainly not ideal for the reasons you pointed out.

From what I can tell it doesn't fit into the existing API, so my goal was to get a conversation going to see if we could find a "simple" solution from a technical implementation perspective, that inherently provided what I'll call an "intuitive pseudo" workflow to our users which kept the integrity of Author and Editor intact in all scenarios, while also not introducing concepts that wouldn't make sense long term. Perhaps such a solution doesn't exist.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

[Justin Seliga]

Proposed Technical changes

1. Add three new states
1. Awaiting Review
2. Approved
3. Denied
2. If a user is not a Publisher
1. Don't show Authors the state field, always set form value for state to Awaiting Review
2. Show Editors the state field but only with Awaiting Review, Approved, Denied as options
3. Load article edit form with the data from the most recent version.
1. If form saved with Awaiting Review, Approved, or Denied state do not update #_content but still create new #_ucm_history (could this be as easy as a simple conditional?)
4. Display the list of articles in the backend with a second state column labeled "Workflow" that shows the state value for the most recent version.
1. This column can be filtered on (creating a pseudo workflow)
2. If this value is Awaiting Review or Approved Publishers and Editors can quickly see that action needs to be taken respectively.

Potential "Intuitive Pseudo" Workflow?

1. Author creates article which doesn't get set to Published
2. Editor wants a list of all the articles in their conceptual workflow (articles waiting to be reviewed).
1. Uses the new filter field to find articles that have a newer version marked as Awaiting Review.
2. Reviews/Approves/Modifies article and saves with state of Approved, Denied, Awaiting Review, new version created, but #_content isn't updated
3. Publisher wants to see their conceptual workflow (article versions that have been approved but need published)
1. Sets state to Published, new version created, #_content updated to hold this versions content
4. Author makes a change to this article, new version created with status of Awaiting Review, #_content row is untouched.
5. Repeat steps 2 and 3.

What are the issues with this approach? Can it be improved? Is it intuitive to the end user? Is it feasible technically? Does it introduce any concepts that don't make sense in a system that properly implements workflow management?

[Michael Babker]

I'd suggest not tying your workflow to the default access groups.  Remember that we have the somewhat modular ACL system that allows groups to be added and renamed.  So this should be tied into the actual ACL levels I think.  If group has ACL Edit State permissions then allow X otherwise do Y.

In terms of code structure, if I remember right we don't have an external API for actually managing content versions outside JTable.  Which means as we have now, JTableContent would have to make the "save or don't" decision.  Structurally, that's adding responsibilities to a class that it shouldn't have.  But, like I said, this is what we have now.

Is this workflow only intended for com_content?  What keeps this from being integrated into the main MVC classes and theoretically being available to all components?

And sadly there is a backward compatibility concern that needs a decision.  Implementing the flow does make a pretty big change in behavior, even if it is to what's perceived to be right.  Users without Edit State permissions would effectively go from being able to immediately revise published content to being required to wait for someone with permission to review it.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

--
- Michael

Please pardon any errors, this message was sent from my iPhone.

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.

[Justin Seliga]

Just to clarify I used the user group names as conceptual permissions, the decision making in the code would look at the permissions a user inherits from the groups they are in to respect the modularity of the ACL.

I did mention in my TLDR original post your concern about business logic such as this existing in the JTableContent class, certainly not good, maybe a deal breaker?

Could the JTableObserverContenthistory logic be moved out of JTableContent and into the com_content.article controller allowing a decision tree for which should be executed?

I don't necessarily see it as a B/C issue if we're fixing a bug, which we agree this is.

Though a new permission will need to be included like Can Approve/Deny, the old permissions like Can Edit State will mean what they did, just won't be associated with the conceptual Publisher group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

--
- Michael

Please pardon any errors, this message was sent from my iPhone.

[brian teeman]

On Wednesday, 10 June 2015 01:03:34 UTC+1, Justin Seliga wrote:

I don't necessarily see it as a B/C issue if we're fixing a bug, which we agree this is.

I think we agree it could be better but not that it is a bug. The system is working as designed (remember versions came a long time afterwards).

While I agree that your proposal is an improvement, especially for certain sites, if it changes the behaviour on all existing sites then I would personally see it as a b/c issue. If it can be done so that this new enhanced and improved workflow is something that you enable then that would not be a b/c issue

[Bakual]

The way versions work is that they are called AFTER the content is already saved. Currently you can't create a new version entry without actualling saving the article.

That is what would have to be changed first, so you could save an article to version only, without modifying the actual content. That is not an eas thing to do the way versioning works.

If you have that figured out, you would need a way to detect versions which are "future" ones and notify somehow the publishers/reviewers about it. Currently there is no way for that. You would have to create new database queries which check that and change the UI to give publishers a clue that something was proposed there. Also probably not the easiest thing to do in a nice way.

All in all I think it's something to consider for Joomla 4, but not something which can be done in Joomla 3.

For now if it's really important for you I would just disable edit.own for the users and instead let them create new articles if they need to change something.

[Justin Seliga]

Looking forward, is there an opportunity to start planning a proper implementation for Joomla 4?

I've seen some discussions suggesting UCM was a failed concept and needs to be scrapped, perhaps a decision on that is required first?

[Nils Rückmann]

Am Mittwoch, 10. Juni 2015 15:01:21 UTC+2 schrieb Justin Seliga:

Looking forward, is there an opportunity to start planning a proper implementation for Joomla 4?

I've seen some discussions suggesting UCM was a failed concept and needs to be scrapped, perhaps a decision on that is required first?

Good luck with that ;) 

[Justin Seliga]

It's not overly important to me, the use-case I defined that makes this functionality a "requirement" likely makes up a small percentage of the current Joomla! user base.

I brought it up with a bit of urgency because I am aware of a situation where a decent sized organization is in the market for a new CMS, but the adoption of the product hinges heavily on a decentralized content creation environment, with one department responsible for reviewing before content is available to the public (in all cases, not just the initial publication).

By extension, I assumed that this could be the case in many other situations, and as a result Joomla! could be capitalizing on reaching new markets.

On Wednesday, June 10, 2015 at 4:55:47 AM UTC-4, Bakual wrote:

[Niels Braczek]

Am 10.06.2015 um 15:01 schrieb Justin Seliga:

> Looking forward, is there an opportunity to start planning a proper
> implementation for Joomla 4?

If my proposal for the J4 architecture
(https://github.com/nibralab/joomla-architecture) gets accepted, then it
is possible to implement it that way - even for /any/ table, not just
content. I have it on my list.

Regards,
Niels

--
| New Stars on the Horizon: GreenCape · nibralab · laJoom |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

[Hannes Papenberg]

I love how everyone is either saying "Hey, lets extend the life of 3.x
for the next bazillion years and then work on 4.something when 3.x has
reached its EOL." or "Hey, lets sit down now and start planning for 4.0
and only start work on 4.0 when ALL plans are 300% done and ready. Oh,
and it has to be grant. Maybe a complete rewrite, maybe slightly below
that, but I expect at least the difference of steam- and gas-engine
between 3.x and 4.x"

Can we please start a 4.x branch where people can PR their work against?
Like removing all that legacy code and clean that up? Then at least
something would be happening. Cleaning up all the deprecated methods and
renaming all the protected variables to the proper name like we are
promising to do since Joomla 1.6, would already be a big step forward.

Hannes

[Bakual]

How are you going to update that branch with all the changes that will be done meanwhile in the 3.x repo? That would be an interesting job to do, but not one I have the time myself.

Personally I think removing the legacy things without having a plan at all what Joomla 4 will become is quite useless. Changes are the work is done for nothing in the end.

To my knowledge there was some discussion about J4 happening at JAB. So some starting is done.

[Hannes Papenberg]

We had such discussions on a dozen events and to the death on all
communication channels that Joomla has and in the end nothing happened.

git has been written for exactly the current situation. Yes, we might
have some conflicts when merging the current staging branch into the 4.x
branch from time to time, but we have to start somewhere. Most of the
time however, it should be a smooth merging operation.

I'm talking about at least removing all the deprecated stuff that we
have. JUserHelper for example has 18 methods, 7 of which are deprecated
or unused right now. Considering that we might be talking about 30% less
code after we simply cleaned all of this up, should make the discussion
simpler. Then there are our MVC classes, which still contain properties
with underscore prefix. This is from Joomla 1.5 and we already decided
in 1.6 that we would remove those underscores. JUser has 5 of those
legacy properties, JTable has 12. Simply start by cleaning that stuff
up. Provide a branch that people can do PRs against, for gods sake! For
the last 5 years I basically got the answer "Write the code and we might
look at it." But when I don't even have a branch where I can base this
of, then you will definitely not look at my code. Or are you interested
to wade through 20 commits with different code changes for showing how
to improve JForm? That is what PRs are for.

tldr: Create a 4.x branch and let people propose PRs against that.

Hannes

> <https://github.com/nibralab/joomla-architecture>) gets accepted,

> then it
> > is possible to implement it that way - even for /any/ table, not
> just
> > content. I have it on my list.
> >
> > Regards,
> > Niels
> >
>

> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to joomla-dev-cm...@googlegroups.com
> <mailto:joomla-dev-cm...@googlegroups.com>.
> To post to this group, send email to joomla-...@googlegroups.com
> <mailto:joomla-...@googlegroups.com>.

[Nils Rückmann]

Am Mittwoch, 10. Juni 2015 21:12:05 UTC+2 schrieb Hannes Papenberg:

tldr: Create a 4.x branch and let people propose PRs against that.

Or: Give us a playground to refactor the whole CMS :) 

[Michael Babker]

We tried that once.  Didn't go over well :-D

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.

[Bakual]

There is still the Icarus repo (https://github.com/joomla-projects/icarus) which was originally meant for that :-)
Or there is https://github.com/joomla-projects/joomla-cms which serves as a playground for many things.

One could create a branch with a "cleaned" J4 there. No problem, just create a PR. Still would be a snapshot of the current staging and it will be hard to keep up to date with staging as there will be many merge conflicts.

I just don't want to have a J4 branch in the main repo at this stage. I don't think it makes much sense without having yet a vision/plan what J4 should be.

[Hannes Papenberg]

Then tell me how you expect that vision to be decided on.

Looking through the different initiatives and mails to this list, I
think I could come up with at least 4 competing visions for Joomla 4 and
so far this always failed because we reached a point where a decision
would have to be made which way to go and that didn't happen. So when no
one wants to decide/be responsible for the next version or let those
willing to do so take over, we have to take a different route. Providing
a branch would be that other way, because it would allow people to put
code where their mouth is and provide something that can be discussed.
We are at the current stage somewhere since 2012.

Hannes

[brian teeman]

Such a shame that you were not at JAB15 as there were great discussions there about this

[Hannes Papenberg]

So unless I visit every JAB, maybe even every JoomlaDay, I'm not allowed
to voice my opinion on this? Especially since I also had great
discussions about Joomla 4/the future of Joomla at JAB 13 and JAB 12.

Am 11.06.2015 um 10:36 schrieb brian teeman:
> Such a shame that you were not at JAB15 as there were great
> discussions there about this

[Bakual]

There will be progress this year.

> an email to joomla-dev-cms+unsubscribe@googlegroups.com
> <mailto:joomla-dev-cms+unsub...@googlegroups.com>.
> To post to this group, send email to joomla-dev-cms@googlegroups.com
> <mailto:joomla-dev-cms@googlegroups.com>.

[brian teeman]

thats not what I said

[Michael Babker]

The main gripe I'm seeing (and agree with) is that when it comes to leadership making decisions on the software for anything beyond 3.x, that's where everything dies.  Even the discussions at JAB were more community lead and involved than leadership.  And again this thread is going in a "when we (PLT) are ready to focus on 4.0 then everyone can start working toward it but until then it's all discussion that's going to go nowhere" direction.

> an email to joomla-dev-cm...@googlegroups.com
> <mailto:joomla-dev-cm...@googlegroups.com>.
> To post to this group, send email to joomla-...@googlegroups.com
> <mailto:joomla-...@googlegroups.com>.

> Visit this group at http://groups.google.com/group/joomla-dev-cms.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.

To post to this group, send email to joomla-...@googlegroups.com.

[Sergio Manzi]

There should be a different leadership (maintainers, committers, etc.) for every new upcoming major version.
See what Drupal does (well, of course under the "benevolent dictatorship" of Dries and Acquia in their case...):

https://www.drupal.org/contribute/core-maintainers

It works.

[Webdongle Elgnodbew]

@Michael Babker
Is that really surprising ?

> <mailto:joomla-dev-cms+unsub...@googlegroups.com>.

> To post to this group, send email to joomla-...@googlegroups.com
> <mailto:joomla-...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/joomla-dev-cms.
> For more options, visit https://groups.google.com/d/optout.

[El KuKu]

Every time it happens  (again and again) it's always a new surprise. ...

Again and again it's surprising seeing posts that seem to contain nothing but frustration about the future of Joomla!

Why?

> an email to joomla-dev-cm...@googlegroups.com
> <mailto:joomla-dev-cm...@googlegroups.com>.

> To post to this group, send email to joomla-...@googlegroups.com
> <mailto:joomla-...@googlegroups.com>.

[Marco Dings]

We are already considering adding Content Staging to the versioning, and the revised architecture under discussion may also aid in that.

At this point in time we are striving for a controlled build up for Joomla4, no open "playground"/ git repo is considered. That has nothing todo about being secretive, it is all about beeing effecient and controlled.

Anybody interested and committed to contribute is invited to contact me to join the Joomla4 working group.

Marco - Joomla4 working group

Be like me, be Carbon free - don't print this and save a tree

IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email by mistake, please notify the sender immediately and do not disclose the contents to anyone or make copies thereof.

[Nils Rückmann]

There's a dedicated Joomla 4 working group?

[Marco Dings]

Yes it was officially instantiated at the PLT summit after JAB15 and it is in the process
of ramping up hence we have not given it wide publicity yet.

Anybody interested and committed to contribute is invited to contact me to join the Joomla4 working group!!!

[Sergio Manzi]

Nice to know...

[Nils Rückmann]

Sounds like the old behavior. Planning behind closed doors, creating a fact and hope that the community won't rebel.

[Michael Babker]

Our apologies that a group of us sat down together at JAB to come up with some ideas and that it's taking a little bit of time to get everything organized post conference?

--

[Sergio Manzi]

Michael,

as you probably know I have you in great esteem, both as a programmer and as a person, but I think you're wrong with this and Nils is right, so please let me explain my thoughts.

The problem is that there is a "you-us" and a "the-others-us", a "inner-circle" and a "outer-circle", and the inner-circle is not yielding in terms of transparency.

We discover here, after days of discussion about a "future enhancement", after several person have asked for a playground for the next-big-thing, after having been reminded the ill-fated Icaurs project (nomen est omen... ), that a "Joomla4 Working Group" exist, that Marco Ding (just as there are no miscomprehension, I don't know him at all, an thus I can't say anything bad or good about him) is apparently in charge of it and that you are waiting for "everything being organized" to give the announcement.

Sorry, but I don't think this is the way to manage an open source project to which so many contribute and has equality amongst its declared values.

What I had personally done is to publish in the official communication channel (is this the official communication channel with the community at large, and, if not, what is it?) the fact that at JAB the idea/need to set-up a Joomla4 WG had emerged and the discussion was open about ideas, nominations and whatever else. This is managing an open community of equals, IMHO...

With the greatest and sincere regards,

Sergio

[Michael Babker]

I'm not the one managing communication these days so I'll leave that alone.  All I can say is give the PLT folks a little bit of time.  For those unaware, those from the team who attended JAB (it was most of them) had a 2-day summit afterward so in many cases a lot of them didn't actually get home from JAB until 3-4 days after the event.  That's about 8 or 9 days ago now.  Enough time for them to get settled in and caught up with their day jobs while processing all the JAB activity.

Can it be done better?  Always.  The group of us who sat down at JAB was really organized in the days leading up to the event and wasn't a leadership driven thing; actually the results of that discussion was given to PLT to decide on whether it was feasible to use as a foundation to move forward on.  IT WAS NOT A LEADERSHIP ORGANIZED DISCUSSION. (Yes I feel the need to emphasize that)

The fact that it got announced in this group in a passing manner at best doesn't intend to come off as dismissive or closed off, I promise.  I saw someone griping on social media that teams meeting in person at events was exclusive to the greater community because not everyone can be there; in ways they're right but holy crap you can get a lot done when you put a group around a table to focus for a few hours.  Those discussions were only the beginning of things, I doubt anyone is going to say "this group of whoever are the only ones allowed to define the next major release" and if they do then we have bigger problems.

Long and short, give folks a chance.  Nobody is trying to exclude anyone right now, rather folks are working on presenting an organized team and the foundation for future discussions so we don't end up with another series of releases where it's just "so there's this random code floating around, let's merge it" (and really that's what a lot of the first few 3.x releases were, there was no real plan).  The volunteer portal is supposed to be authoritative with what groups are active and their membership (BTW how are we doing on that?), so here you go - http://volunteers.joomla.org/working-groups/joomla-4-working-group

I know it's easy to dismiss what I'm saying because I'm part of that perceived "inner circle", but take it from one of those "inner circle" people who are mostly rogue and doing their own thing, this is probably one of the best organized code related groups that I've seen get started in a while.  And I've seen a lot of them form, including a few started on my own.

[brian teeman]

Well said

[Bakual]

Huh? The group isn't even fully formally created and already people are complaining about it? Marco especially invited people interested to be part of that group. That's not closed doors. That's how most of our working groups actually work. Like for example also the JBS.

By the way Marco Dings is our newest PLT member. There is nothing wrong with him forming and leading a Joomla 4 working group. And as Michael already explained it's a result of JaB and the following 2day PLT meeting which only happend recently.

There is no hiding at all. There is no inner-circle doing anything veiled in conspiracy. It's how working groups are started and formed. Or do we now need a public discussion bevore we even start a working group? That's silly.

So if you are interested in helping build Joomla 4, get in contact with Marco so you can be added to that working group he is forming. We need you on the productive side. Not on the critisising side, we already have enough people on this side.

[Nils Rückmann]

I'm sorry, if my comment sounded too harsh. It wasn't my intention to blame somebody in person. It's more like a general thing. I think it's absolutely fine, if the PLT (or another leadership) decides about working groups and their purpose. But what i miss is a standard workflow for such things. Like:

1. PLT decides to create a new working group
2. PLT discusses the purpose/scope of this working group internally

3. PLT announces the new working group

4. Working group can now be managed by itself (advertise, invent members etc.)

The crucial part is the announcement. That's the point everybody gets disappointed today, because the announcement always comes to late and in totally unexpected places.

I've mentioned this months before, but there are still to many pages where working groups are officially listed, but never have been in the same state:

http://volunteers.joomla.org/working-groups

https://docs.joomla.org/Production_Working_Groups

http://www.joomla.org/about-joomla/the-project/project-teams.html

So let's drop the duplicates and focus on a single page where all volunteers can trust it.

[Marco Dings]

Why would you say/assume that when we invite people in to contribute ?
We have no intention of secrecy, we will be reporting, and at the same time
we need to make progress and that requires focus.

[Marco Dings]

Sergio, you are welcome to contribute, in that sense there is no "you-us" "the others". I'm sorry that you feel there is no transparency but please consider we are finding our bearing and we have only been at this "officially" since after JAB. One of the challenges of the project is that "stuff" is discussed at multiple locations which makes it difficult to cover all, so my appologies for catching on for this "late".

Hit me up on glip or skype ( marcodings) to get to know each other.

We will be reporting, amongst others through the volunteer portal, The outcome of the make it happen session is not complete enough to share as it would raise more questions than it would answer. We are all volunteers, so things will move more slowly than i would expect in a "business" environment.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

[Anibal]

Hi,

About Joomla 4, I have found that Jessica's presentation has an excellent review of the current ideas and future plans:

Joomla! Tomorrow and Beyond 

https://www.youtube.com/watch?v=mrMufewnAw4

http://www.slideshare.net/jessicadunbar/joomla-tomorrow-and-beyond

[George Wilson]

I can largely take the blame for some of this - I was the one in charge of writing up the PLT minutes from JAB and have finished writing everything up tonight - so once everyone's read them and agreed that I haven't missed anything or misconstrued anything (hopefully will be done in a few days) then we'll have them public on the volunteer portal. For what it's worth though even at the PLT summit because not everyone was present we voted on the formation of the group by email so it wasn't fully created until after we left Prague. 

The official communication for working group matters would be the volunteer portal where we have set up a working group http://volunteers.joomla.org/working-groups/joomla-4-working-group Currently it is just based on the people who sat down at JAB to make the proposal that was submitted to PLT.

FWIW when we opened up for ideas with Icarus everything fell apart so the idea this time is to take a much more structured approach - setting up that structure takes time however - and when that's ready we can look to take more people on board and open up the ideas made at JAB to the community for feedback.

Neils as for the place for working groups we are aware the docs page is out of date and one of the action items from JAB is to get that in line with what is on the volunteer portal. Also RE: the workflow generally what should happen is a group of like minded people getting together to form a group (like what happened with webservices, or the admin template group etc.) that then submit to be a formal working group than the PLT deciding to create a group out of thin air and hoping people go into it.

Hopefully this answers a few peoples questions!

Kind Regards,

George

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.

[ssnobben]

This problem I heard from other people in the Joomla community --> "the communication for everyone transparent problem" and it also seems difficult to solve and manage. And of course it’s a challenge

.

1. "The problem is that there is a "you-us" and a "the-others-us", a "inner-circle" and a "outer-circle", and the inner-circle is not yielding in terms of transparency."

2. "One of the challenges of the project is that "stuff" is discussed at multiple locations which makes it difficult to cover all, so my appologies for catching on for this "late"."

The problem is that other than you "inner-circle" PLTs experience this is a kind of problem and why not listening careful when this input comes from people like Sergio?  Even I don’t know Sergio I care very much for his support/opinion for Joomla project in the long run. He is not stupid. And if he says and got this feeling it's important to try to understand w h y this is like this. Don’t you agree?

So let's also to discuss how to improve this somewhere bcs you can't ask you, the PLT core members this type of question I f this is a problem and think they are not biased. You are part of the problem and don’t see it and don’t understand it. But it's good that you are aware of it.

I think this problem(s) also should involve the marketing team that should look into this communication/marketing/info flow and analyse what can be improved in many ways for Joomla as a whole.

So any reflection about how to improve the communication flow and how it should be done better not putting on the cave man defensive – nothing wrong here?

As this said: "The official communication for working group matters would be the volunteer portal where we have set up a working group http://volunteers.joomla.org/working-groups/joomla-4-working-group"

Why isn’t this announcing in the Joomla front page first "Developer news" and all of our activities forced to be announce there first? You don’t have to tell the whole story just prepare the community what going on…

In my opinion Joomla nowadays have toooo many channels and too little focus on the primary Joomla announcement front page site  --> Joomla.org  Maybe an overview about how to do a better info management work flow chart of what Joomla want to show for the world and create engagement there would be a good idea? Our front page should be reviewed regularly to meet up with changes that are going in for Joomla.

Maybe we could have more "active" information coming in there to show what activities going on from everywhere let it be phpBB forum discussions topics, Magazine teasers article extract, developer news, marketing activities, new releases, new released great Joomla sites, Latest Joomla tips etc etc whatever but show its activities going on in the Joomla world. 

As now the info there is little bit too "old" info there and could have more frequent updates in my opinion.  Maybe have some twitter, LinkedIn info flows about discussions in a right column etc

So news should be seen logically on front page first and then discussed leading people in the other Joomla groups of activities ie development, marketing, twitter, LinkedIn etc.

Small example of this discussed topic under "Developer News"  "New Joomla 4 group is going to be created" – please join to discuss here http:-----.org and participate here http://volunteers.joomla.org/working-groups/joomla-4-working-group

Thanks all Joomla heroes!

 

[Sergio Manzi]

I'm not answering to anyone particularly with this... a little bit to everybody...

• I'm sure there are good intentions in all/most the xLT members and primary focus for everybody/most is Joomla! "health".
  
  
• Anyway I think a broader reflection must be done on what the participation model to this project is, and as a consequence what the xLT managing style should be and what their "compass" should be.
  
  E.g: is "efficiency"  a more important value than "democracy"? Who should we "please" first? 3rd party developers or the community at large? If "equality" and "democracy" are amongst our guidelines, how should we implement those principles?
  
  I'm fully aware it is not an easy task at all. It is really similar to governing a small country, and a very peculiar one, in which so many different cultures are represented... What would you like for your country? A benevolent (hopefuly...) illuminated dictatorship/aristocracy or a fully realized democracy (be it a direct or representative one)?
  
  
• Some examples of things I didn't care for much:
  
  - The adoption of the "New structure" have been announced (http://community.joomla.org/blogs/leadership/1861-joomla-leadership-adopts-new-structure-a-methodology.html) and even some clarification about it has been published (e.g: http://community.joomla.org/blogs/leadership/1865-questions-on-structure-reform.html), but why the text of the adopted document has not been conspicuously been published on www.joomla.org? Where is it? Is it the same proposal that was proposed for feedback (https://docs.google.com/document/d/1U_rnfymS0LJdd67SUqCqi07oetDWK_DJj8rsbIBKbEg/edit?pli=1)? If yes, do you really see that "placing" (a google docs document) fit for our "Magna Charta"?
  
  - What is the process for being "drafted-in" the xLTs? A nomination by the xLTs members? If I'm not mistaken this is how it goes, and if this is how it goes it seems quite obvious that the xLTs will be self-perpetrating organisms. PLT has a form to propose someone for membership  (https://docs.google.com/a/joomla.org/spreadsheet/embeddedform?formkey=dHU5LUVMLXRIR0dSV3dyTElKYVZjMVE6MQ) I used it and I proposed someone (and, no, it wasn't myself at all!!). After that... what? There is no place where to see what the proposal have been? No feedback on how many "votes" someone has received? Everything goes into a black hole and then the PLT itself takes decisions at its final and imperscrutable discretion?
  
  - Why are WG in a way "mushrooming"? Why do we have not one, but four WG (largely made up by the same persons) about "Certification"? Has this something to do with the mechanisms of the "New structure"? As a great (and much discussed) Italian politician of the recent past said: "It's a sin to think ill, but you're seldom mistaken"
  (This was just an example, nothing specifically against the certification initiative...)
  
  - If I'm not mistaken, having the "New structure" being adopted we should now in the "transition period". Any details about that?
  
  - back on point about the Joomla4 WG: I see very nice names in it, people who have all my respect, but, what if someone have a different idea? What if a group of 2-3 persons would like to propose a different approach (this is totally theoretical, as we don't even yet know what the proposed approach will be...)? Would it be possible to form a Joomla4-B WG and then have the community at large cast their votes about the different approaches?
  
  
• ssnobben is absolutely right: "(we) have toooo many channels and too little focus on the primary Joomla announcement front page site  --> Joomla.org". I would add that the joomla.org front page is not enough: a more "direct" communication channel (this or any other similar mailing-list or an RSS feed) should also be used to notify about important "facts" about our community.

Sincerely,

Sergio

[brian teeman]

To answer your comment about certification groups. These groups have been in existance for almost two years now and all serve different purposes as per their title. So nothing to do with the "new structure" at all

[Sergio Manzi]

I think "almost two years" is a bit of a stretch, but thanks anyway!

Certification Extension Team: first membership Mar 2015
Certification Marketing Team: first membership Jan 2014
Certification Operations Team: first membership Jan 2014
Certification Exam Team: first membership Jan 2014

In any case I really didn't want to point my finger at those WG in any special way...

[Michael Babker]

Not all the dates on the portal are accurate.  Some are just when they got added to the team in the portal.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.

[Sergio Manzi]

OK, no prob... just disregard my reference to those WG and take my original statement as  a generic one.

My apologies to those WG for singling them out: it was a mistake and I really haven't anything against them apart my personal feeling that there is some redundancy (but this is just my opinion).

[Michael Babker]

Well if the volunteer portal were as authoritative as it's suggested it should be in various places (including the structure proposal), you wouldn't have to make that disregard statement ;-)

[George Wilson]

I'll try and answer the questions you've posed to the best of my ability :) Note this isn't what is and isn't "right" it's trying to give factual answers of what is actually taking place.

• - The adoption of the "New structure" have been announced (http://community.joomla.org/blogs/leadership/1861-joomla-leadership-adopts-new-structure-a-methodology.html) and even some clarification about it has been published (e.g: http://community.joomla.org/blogs/leadership/1865-questions-on-structure-reform.html), but why the text of the adopted document has not been conspicuously been published on www.joomla.org? Where is it? Is it the same proposal that was proposed for feedback (https://docs.google.com/document/d/1U_rnfymS0LJdd67SUqCqi07oetDWK_DJj8rsbIBKbEg/edit?pli=1)? If yes, do you really see that "placing" (a google docs document) fit for our "Magna Charta"?
  

The proposal in the document you referenced is almost the same thing that got voted in. The only change was a little bit extra on the transition teams and formalising how working groups would be made for the two missing areas (the code of conduct and ombudsman). The final version is the one in the (public) vote at https://groups.google.com/forum/#!topic/joomla-leadership/wX1YYLN3lKY . You're right the final approved version should have been linked to in that forum post - I wasn't aware of that - apologies.

 

• - What is the process for being "drafted-in" the xLTs? A nomination by the xLTs members? If I'm not mistaken this is how it goes, and if this is how it goes it seems quite obvious that the xLTs will be self-perpetrating organisms. PLT has a form to propose someone for membership  (https://docs.google.com/a/joomla.org/spreadsheet/embeddedform?formkey=dHU5LUVMLXRIR0dSV3dyTElKYVZjMVE6MQ) I used it and I proposed someone (and, no, it wasn't myself at all!!). After that... what? There is no place where to see what the proposal have been? No feedback on how many "votes" someone has received? Everything goes into a black hole and then the PLT itself takes decisions at its final and imperscrutable discretion?#
  

So this is something that personally I feel PLT is weak with compared to CLT but I'll try and explain what the current procedure is (note that doesn't mean I agree with all of it!). I honestly can't remember who you nominated now (it was like 6 months ago!) but we include everyone nominated by that form on the list of people to vote on. We always individually contact those who are nominated (although not the people who nominate them) to let them know if they were successful or not. However currently we don't publish the results of the votes out of respect to the people nominated who didn't get in.

 

• - Why are WG in a way "mushrooming"? Why do we have not one, but four WG (largely made up by the same persons) about "Certification"? Has this something to do with the mechanisms of the "New structure"? As a great (and much discussed) Italian politician of the recent past said: "It's a sin to think ill, but you're seldom mistaken"
  (This was just an example, nothing specifically against the certification initiative...)

I think that subgroups are going to become more prominent. For example I *think* the Joomla 4 WG is going to have SubTeams for architecture, UX  etc. (note as I said earlier the group is still deciding on a structure so it might not end up this way when it get publicly announced) and the question is whether you add all those subteams onto the volunteer portal like the certification team have or whether you just list the parent body on the volunteer portal. It will take a while I think to settle on what the best approach is.

 

• - If I'm not mistaken, having the "New structure" being adopted we should now in the "transition period". Any details about that?
  

See this currently in progress vote about the formation of the transition team (that should be comprised of the community) https://groups.google.com/forum/#!topic/joomla-leadership/vOijseuyh3M

• - back on point about the Joomla4 WG: I see very nice names in it, people who have all my respect, but, what if someone have a different idea? What if a group of 2-3 persons would like to propose a different approach (this is totally theoretical, as we don't even yet know what the proposed approach will be...)? Would it be possible to form a Joomla4-B WG and then have the community at large cast their votes about the different approaches?
  

If people got together and found an alternative proposal my personal opinion is that the PLT would have to consider it. Although it would need to be comprised of more than a few ideas jotted down. I think we would expect/need at least a base description on how you want to improve the architecture of the CMS for the next 5 years and the features you want to add for site users over the next 5 years. Otherwise again we end up with the issues we had in icarus where people just argued so hard over everything that nothing actually got done. Having said that at some point before code starts to be written we would pick a proposal - we should not be coding two proposals at the same time - it makes no sense to get people too involved and then upset when the stuff they put so much time into isn't picked and also we don't really have those resources when we are still going to maintain 3.5.

 

•  ssnobben is absolutely right: "(we) have toooo many channels and too little focus on the primary Joomla announcement front page site  --> Joomla.org". I would add that the joomla.org front page is not enough: a more "direct" communication channel (this or any other similar mailing-list or an RSS feed) should also be used to notify about important "facts" about our community.

I think this is something EVERYONE agrees with but in practice is much harder said than done. There's a big marketing movement onto restructure and clean up the content on ALL the Joomla subdomains and merge some of them together so things are more manageable and easier to find. This initiative was started in a JAB Make it Happen session as well - but honestly you'd need to contact them. Joomla.org is actually formally under CLT control so there's limited amounts the PLT can do to help. The issue is what's "important" to people - what's important for one person isn't for another. For example at my local JUG they don't care what the leadership structure is as long as there is a viable end product that they can use (and contribute to when time allows) - so is that "important"? Clearly for many people it is - but you get the idea - that kind of stuff is super hard to judge what is important.

Whilst you may not agree with every point hopefully this gives you some answers :)

Kind Regards,

George

[Sergio Manzi]

First of all I would like to apology with Justin Seliga: it really seems I/we have hijacked your thread... sorry!

George,

thanks for answering, but, as you might imagine, there are many points I don't agree with. I will not go into details as it will just be a repetition of what I stated in the post you answered to, but, as usual, any answer brings new questions!   :-)

=========================

I've carefully read the motion the LTs are now voting about the "Procedure formation of the Transition Team" and I urge anybody on this list to do the same.

If I read it correctly:

• The transition team will be formed by 9 members: 3 from the LTs and 6 from the community at large AND/OR the LTs.
• Nominations will be open (but where this will be announced?)
  
• LTs will "interview" the nominees
• The LTs will discuss and create a shortlist (on which criteria?)
• The LTs will pick (private ballot) the members from the shortlist

So, in essence, the LTs will have control on the team (committee) that will steer the transition from the current LTs to the new LTs. If this is really the case I find this is contrary to the basic tenets of democracy and law of order and I urge everyone in this community to express his/her voice, and I ask all current LTs members to vote against this motion.

=========================

About communication channels, you say that everybody agrees that a problem exist, but (solving it) "... in practice is much harder said than done." (sic!)
I do agree!! :-) This list (and particularly this thread!) is probably not the correct place, but it would be quite easy to create a new Google Group dealing with Joomla! community matters (e.g: joomla-community):

we already have:

• Joomla! CMS Development (https://groups.google.com/forum/#!forum/joomla-dev-cms)
• Joomla! General Development (https://groups.google.com/forum/#!forum/joomla-dev-general)
• Joomla! Documentation (https://groups.google.com/forum/#!forum/joomla-docs)
• Joomla! Framework Development (https://groups.google.com/forum/#!forum/joomla-dev-framework)
• Joomla! Platform Development (https://groups.google.com/forum/#!forum/joomla-dev-platform) [defunct]
• Joomla Leadership Team (https://groups.google.com/forum/#!forum/joomla-leadership) [read-only for non-LT members]
• Joomla! Community Working Group Leadership (https://groups.google.com/forum/#!forum/joomla-wg-community) [read-only for CLT/CWG members]

None of them seems fit for community announcement/discussion, so I propose to create such a new group, announce its creation on the existing groups and on www.joomla.org home page, and from then on use that group for community related topics. The LTs, should feel obliged to publish any decision/fact/minutes/etc. on that new group, open to public discussion to registered users.

=========================

A question is buzzing in my head:

Should we all Joomla! contributors apply for OSM membership? This will probably be the correct way to steer the future of Joomla!...
How one do apply for OSM membership?
Is membership open or subject to the vetting by  current members?

=========================

Thanks!

Sergio

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.

[Bakual]

To answer the last question:
Currently, only OSM board members are members of OSM. No other members and no way of getting member without getting elected into OSM board.

With the new structure, every member of any Joomla working group will automatically become member of OSM and is allowed to vote.

At least that's how I understood it.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.

[Hannes Papenberg]

Hi George,
I really hope that Joomla 4.x will not be our development branch for the
next 5 years. Even when I personally hope that it's maybe around 3
years, that would be pretty long. 5 years ago, we would have been
talking almost exclusively about mobile-optimizing for the iPhone 3G,
etc. If Joomla 4.x will be our only development branch for the next 5
years, we might as well tell our users "Joomla will not evolve after the
release of 4.0. Feel free to sleep the next 5 years." And while
everybody loves stability, it would make it extrem hard for me to sell
my customers a system that is even further behind than it already is.

Could we please get away from the idea that we have to create something
perfect for the next quadrillion years? I really don't understand the
position that many here have. We have a promise to our users that we are
using semantic versioning and that we provide them with at least 2 years
of support after the last minor release. That means that we can release
new major releases maybe every 2 years. That does NOT mean that people
have to upgrade directly. It means that they have at least 2 more years
that they get out of their investment.

At the same time it allows us to raise requirements and implement good
features in new versions in a reasonable timeframe. Telling a developer,
that his code might see the enduser in ~5 years, is just not okay. And
that is the case for anything that might break backwards compatibility
right now.

Making this clear: Expecting to get 5 years of active development out of
a major release without breaking backwards compatibility is a sure way
for us to make Joomla unpopular.

Hannes

Am 15.06.2015 um 22:19 schrieb George Wilson:
> I'll try and answer the questions you've posed to the best of my
> ability :) Note this isn't what is and isn't "right" it's trying to
> give factual answers of what is actually taking place.
>

> * - The adoption of the "New structure" have been announced
> (http://community.joomla.org/blogs/leadership/1861-joomla-leadership-adopts-new-structure-a-methodology.html
> <http://www.google.com/url?q=http%3A%2F%2Fcommunity.joomla.org%2Fblogs%2Fleadership%2F1861-joomla-leadership-adopts-new-structure-a-methodology.html&sa=D&sntz=1&usg=AFQjCNHE9Zl6-7m_piSzUaKci3ol_JLB_g>)

> and even some clarification about it has been published (e.g:
> http://community.joomla.org/blogs/leadership/1865-questions-on-structure-reform.html

> <http://community.joomla.org/blogs/leadership/1865-questions-on-structure-reform.html>),

> but why the text of the adopted document has not been
> conspicuously been published on www.joomla.org

> <http://www.joomla.org>? Where is it? Is it the same proposal

> that was proposed for feedback
> (https://docs.google.com/document/d/1U_rnfymS0LJdd67SUqCqi07oetDWK_DJj8rsbIBKbEg/edit?pli=1

> <https://docs.google.com/document/d/1U_rnfymS0LJdd67SUqCqi07oetDWK_DJj8rsbIBKbEg/edit?pli=1>)?

> If yes, do you really see that "placing" (a google docs

> document) fit for our "/Magna Charta/"?

>
>
> The proposal in the document you referenced is almost the same thing
> that got voted in. The only change was a little bit extra on the
> transition teams and formalising how working groups would be made for
> the two missing areas (the code of conduct and ombudsman). The final
> version is the one in the (public) vote
> at https://groups.google.com/forum/#!topic/joomla-leadership/wX1YYLN3lKY
> . You're right the final approved version should have been linked to
> in that forum post - I wasn't aware of that - apologies.
>

> * - What is the process for being "drafted-in" the xLTs? A

> nomination by the xLTs members? If I'm not mistaken this is
> how it goes, and if this is how it goes it seems quite obvious
> that the xLTs will be self-perpetrating organisms. PLT has a
> form to propose someone for membership
> (https://docs.google.com/a/joomla.org/spreadsheet/embeddedform?formkey=dHU5LUVMLXRIR0dSV3dyTElKYVZjMVE6MQ

> <https://docs.google.com/a/joomla.org/spreadsheet/embeddedform?formkey=dHU5LUVMLXRIR0dSV3dyTElKYVZjMVE6MQ>)//I
> used it and I proposed someone/(and, no, it wasn't myself at
> all!!/). After that... what? There is no place where to see
> what the proposal have been? No feedback on how many "/votes/"

> someone has received? Everything goes into a black hole and
> then the PLT itself takes decisionsat itsfinaland
> imperscrutable discretion?#
>
>
> So this is something that personally I feel PLT is weak with compared
> to CLT but I'll try and explain what the current procedure is (note
> that doesn't mean I agree with all of it!). I honestly can't remember
> who you nominated now (it was like 6 months ago!) but we include
> everyone nominated by that form on the list of people to vote on. We
> always individually contact those who are nominated (although not the
> people who nominate them) to let them know if they were successful or
> not. However currently we don't publish the results of the votes out
> of respect to the people nominated who didn't get in.
>

> * - Why are WG in a way "/mushrooming/"? Why do we have not one,

> but four WG (largely made up by the same persons) about

> "/Certification/"? Has this something to do with the
> mechanisms of the "/New structure/"? As a great (and much
> discussed) Italian politician of the recent past said: /"It's
> a sin to think ill, but you're seldom mistaken/"
> (/This was just an example, nothing specifically against the
> certification initiative.../)

>
> I think that subgroups are going to become more prominent. For example
> I *think* the Joomla 4 WG is going to have SubTeams for architecture,
> UX etc. (note as I said earlier the group is still deciding on a
> structure so it might not end up this way when it get publicly
> announced) and the question is whether you add all those subteams onto
> the volunteer portal like the certification team have or whether you
> just list the parent body on the volunteer portal. It will take a
> while I think to settle on what the best approach is.
>

> * - If I'm not mistaken, having the "New structure" being

> adopted we should now in the "transition period". Any details
> about that?
>
>
> See this currently in progress vote about the formation of the
> transition team (that should be comprised of the community)
> https://groups.google.com/forum/#!topic/joomla-leadership/vOijseuyh3M
>

> * - back on point about the Joomla4 WG: I see very nice names in

> it, people who have all my respect, but, what if someone have
> a different idea? What if a group of 2-3 persons would like to

> propose a different approach (/this is totally theoretical, as

> we don't even yet know what the proposed approach will

> be.../)? Would it be possible to form a Joomla4-B WG and then

> have the community at large cast their votes about the
> different approaches?
>
>
> If people got together and found an alternative proposal my personal
> opinion is that the PLT would have to consider it. Although it would
> need to be comprised of more than a few ideas jotted down. I think we
> would expect/need at least a base description on how you want to
> improve the architecture of the CMS for the next 5 years and the
> features you want to add for site users over the next 5 years.
> Otherwise again we end up with the issues we had in icarus where
> people just argued so hard over everything that nothing actually got
> done. Having said that at some point before code starts to be written
> we would pick a proposal - we should not be coding two proposals at
> the same time - it makes no sense to get people too involved and then
> upset when the stuff they put so much time into isn't picked and also
> we don't really have those resources when we are still going to
> maintain 3.5.
>

> * ssnobben is absolutely right: "(we) /have toooo many channels

> and too little focus on the primary Joomla announcement front

> page site -->////Joomla.org/". I would add that the
> joomla.org <http://joomla.org> front page is not enough: a

> more "direct" communication channel (this or any other similar

> mailing-list or an RSS feed) should *also *be used to notify

> about important "facts" about our community.
>
>
> I think this is something EVERYONE agrees with but in practice is much
> harder said than done. There's a big marketing movement onto
> restructure and clean up the content on ALL the Joomla subdomains and
> merge some of them together so things are more manageable and easier
> to find. This initiative was started in a JAB Make it Happen session
> as well - but honestly you'd need to contact them. Joomla.org is
> actually formally under CLT control so there's limited amounts the PLT
> can do to help. The issue is what's "important" to people - what's
> important for one person isn't for another. For example at my local
> JUG they don't care what the leadership structure is as long as there
> is a viable end product that they can use (and contribute to when time
> allows) - so is that "important"? Clearly for many people it is - but
> you get the idea - that kind of stuff is super hard to judge what is
> important.
>
> Whilst you may not agree with every point hopefully this gives you
> some answers :)
> Kind Regards,
> George

> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to joomla-dev-cm...@googlegroups.com
> <mailto:joomla-dev-cm...@googlegroups.com>.
> To post to this group, send email to joomla-...@googlegroups.com
> <mailto:joomla-...@googlegroups.com>.

[Chad Windnagle]

I've said to multiple members of PLT over the last few months:

The #1 priority for PLT should not be "building" Joomla 4.

It should be to define a process by which the community can collaborate to cast a vision for Joomla 4. This way the community is responsible for the innovation, creativity, and will be empowered to build Joomla 4.

Regards,
Chad Windnagle

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.

[Sergio Manzi]

That's curious because article 3 of the OSM Bylaws says:

"Any individual supportive of this corporation's purposes and not otherwise prohibited by any contract, law or regulation from abiding by the terms of these by-laws is qualified to become a Member of the Corporation."

but, yes, then says...

"Applicants qualified under Section 3.1 above, shall be admitted to membership will be determined on a case by case basis, at the sole discretion of the Board and/or Membership Committee. Any "contributor" to Open Source Matters who is supportive of this corporation's purposes and is not otherwise prohibited by any contract, law or regulation from abiding by the terms of these by-laws shall be eligible for membership. A "contributor" shall be any individual who has contributed to improving Open Source Matters and its projects in any form."

So, to make it short, everybody who's contributing to the Joomla!/OSM project (and not otherwise prevented) shall be eligible for membership, but the fact that it will be (or not) is at the sole discretion of the current Board/Membership Committee (which apparently do not generally consent).

Correct? If it is, it sounds more like a "private club" than a 501(c) organization supporting an open source project....

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.

[Omar]

Here's a good article to read and perhaps Joomla is working on a similar strategy?

Why Microsoft Announced Windows 10 Is 'The Last Version Of Windows'
http://www.forbes.com/sites/gordonkelly/2015/05/08/microsoft-windows-10-last-windows/

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.

[Anibal]

Hi Sergio,

I would not jump into conclusions from a paper. It is the community practice that matters.

At the end, we are here with good will (instead of suspicions and distrust... otherwise we will find what we are looking for.... creating conspiracies).

BTW, this thread is wildly off-topic. I suggest to move it to a J4 WG topic.

Best Regards,

[Niv Froehlich]

I'm pleased to see these membership issues being discussed especially in regard to making contributors voting members.

However, I agree that this thread is wildly off topic. 

I hope this discussion will continue in the proper forum, amicably, with interaction and involvement from members of the  Transition Team as well as contributors.

Niv

[Sergio Manzi]

Totally agreed! Is there a way for Google Group maintainers to "prune" this issues in a separate thread?

[Sergio Manzi]

Actually it will require at least 2 pruning:

• One, J4 related
• The other, "community practices" related

[Robert Vining]

Hi Sergio,

What you are asking for (yet ANOTHER. NEW. CHANNEL. for community communication between people and the LT about community matters) already exists on the community forum. Albeit not too many LT members go there to discuss topics. It is the place they expect community members to respond and discuss issues when they request feedback.

http://forum.joomla.org/viewforum.php?f=704

Basically, the justification in the past has been, the Google groups are for code related discussions that coders want to be emailed to their inbox. The forums are for community based discussions where folks can subscribe to threads if they want email notifications, but allows people to respond at a little slower pace.

There are discussions there about the transition team, the leadership restructure, etc... 

I don't necessarily agree with the separation of state, but it is what it is.

[Sergio Manzi]

Hello Robert!

Yes, I'm asking for a new channel for community announcements (and eventually discussion).

As you surely understand there is a huge difference between a forum and a mailing list (albeit a peculiar one like Google Groups is) and the main difference is that with a forum you (person interested) must make yourself active to see if there is anything new in the air (a pull process), while with a mailing list (or RSS feed)  you don't need to make yourself active: you are notified of the news (push process).

For important matters like the ones we are discussing here I'm firmly convinced that a push process is what we need.

After all there are probably good reasons if not only coders, but the LTs themselves use a Google Group for interaction...

One phrase that seems to recur in this thread is "I don't necessarily agree", coupled with "it is what it is": this is puzzling... If this is not your opinion, why don't you express your opinion? And, can't such a thing like opening a new communication channel (which is easier done than talked about and on which apparently everybody agrees) be changed?

Sorry if I'm asking, but are you talking in the name of an official body? I don't see your name in none of the following:

• OSM Board
• Community Leadership Team
• Volunteers Portal Team
• Social Media Team
• Structure Team

which are the the official bodies from which I'd expect an answer to my request (beside the community at large from which I'd expect an expression of consensus or dissent).

Best regards!

Sergio

[Jessica Dunbar]

Sergio,

> Sorry if I'm asking, but are you talking in the name of an official body? I
> don't see your name in none of the following:
>
> OSM Board
> Community Leadership Team
> Volunteers Portal Team
> Social Media Team
> Structure Team

Your comment is unnecessary to Robert - these groups need to be open
where anyone can give feedback and ideas regardless of what groups
they are active in. Can you start a new thread about your request for
an announcement channel?

[Robert Vining]

Hi Sergio,

I'm only commenting as a community member, dating back to 2006.

I've been exactly where you are, asking questions and trying to make sense of the senseless things that seem to occur on a daily basis.

However, I learned a long time ago to pick my battles. Or I will waste months and months of time asking why instead of trying to contribute in some meaningful manner. Not to suggest you aren't contributing by raising these questions, I simply mean to say, they have all been asked before time and time again.

I've found that instead of trying to change how or where they are asked, or discussed, I have found it easier to try to put my own effort in working on some project within the project, whether it be as a Joomla Google Summer of Code co-admin like I did last year, or part of the Governance Working Group that I participated in last year... or simply joining in the last 2 pizza bugs and fun events with my coworkers.

I spent years complaining and arguing over how the project is broken and someone needs to fix it. But after several years of the same old arguments, I learned that I need to just work on what I can work on, and hope that the end result produces a quality Joomla CMS that I can use to build websites with.

To me, the leadership team is making some pretty big changes with the restructure that dates back to 2010. There have been 3 different Governance Working Groups that have worked on various solutions over that 5 year period. This is the first time in 5 years that we have seen some type of progress in the direction of a restructure that may help our organization grow instead of decline, or move sideways all the time.

So I choose not to criticize directly at this point in time, but instead, keep moving along and helping out where and when I can.

If it means responding to you in this thread, then so be it. If it means joining the j4 working group, I might do that as well. But I've learned to be patient and see where things go. Then help when the flag is raised to ask for assistance.

As for a forum vs mailing list, the blogs are posted as the announcements... There is a leadership blog, a community blog and a dev blog. Then they post a forum link for discussions on those blog posts. That's the link I provided earlier. The one to the discussions. Each forum post there links back to a blog post announcement. You can be on the PUSH end of that process by subscribing to the RSS feeds found here:

http://www.joomla.org/rss.html

Just by looking at the above RSS feed page, I believe we already have way too many communication channels as mentioned in a previous post.

I hope that helps in some way.

Have a great day! I'm out for dinner now.

[Sergio Manzi]

a-b-s-o-l-u-t-e-l-y !

I asked the question only because his words had the feeling of a formal statement due the "I do not necessarily agree" premise, and thus I was asking in name of what body he was speaking.

Robert of course, as any other contributor, has all the rights to express whatever opinion!!!

Sorry for the misunderstanding.

[Niv Froehlich]

Bakual

To answer the last question:
Currently, only OSM board members are members of OSM. No other members and no way of getting member without getting elected into OSM board.

With the new structure, every member of any Joomla working group will automatically become member of OSM and is allowed to vote.

At least that's how I understood it.

I do not think this is the correct interpretation - I believe that it's only those appointed by OSM as to Team Leaders will in turn be members of OSM and able to vote in OSM Directors.

Members of any team won't even be able to vote their own Team Leadership - let alone OSM members.

But again - we are not on topic on this thread - I've asked for clarification on the Forum regarding this topic at http://forum.joomla.org/viewtopic.php?f=704&t=888437&p=3311330#p3311330 (and would politely ask that any response be posted on the Forum).

Best,

Niv

[Bakual]

I'm quite sure members will elect their own leaders. That's one of the main point of the new structure.

[Niv Froehlich]

Either I missed that or this is a new revision.  It does appear that under the new provisions, Team Members elect Team Leaders who in turn elect OSM Directors.

(I've since managed to find a copy of the new proposed revisions but not sure if I'm reading the latest version).

That, IMO, would be a wonderful way to balance the contributor / democratic balance that has been missing from the Joomla ecosystem.

For clarification, Team Members do not become OSM Members unless they are Team Leaders, but rather, vote for Team Leaders.

Hopefully I have the correct understanding.

[Sergio Manzi]

On 2015-06-17 13:57, Niv Froehlich wrote:

Either I missed that or this is a new revision.  It does appear that under the new provisions, Team Members elect Team Leaders who in turn elect OSM Directors.

 Niv, as I read it the 7 Department Coordinators (not the Team Leaders) are OSM members and elects the OSM Directors...

This is according to https://docs.google.com/document/d/1_0i-yX8VOVF3gIhGc-17arsAJe4K32I1ZVLq6dHCJHo/edit?pli=1#heading=h.n8rmze41kp9q which I don't know if it is the final and approved document describing the "New Structure". Is it?

[Niv Froehlich]

Yes - I think that's the latest revision.

Discussion continued on Forum at http://forum.joomla.org/viewtopic.php?f=704&t=888437

--