Releases, Continuous Feedback and bug reports

I know some of you have been disappointed by my last post about discontinuing the Liferay 7.2 Community Beta Program. I understand. It was also hard for us to let it go. But I do believe there is much better way to have an open discussion with you other than setting time constraints and strict rules.

As you all know, Liferay Portal CE is an Open Source product developed in public. We want to make sure everyone feels welcome to contribute and influence its future at any point in time. And this is not something unique to us. Many, if not all, Open Source projects work this way. So we are not going to reinvent the wheel and will simply follow the established best practices.

That said, we need everyone to have full understanding of what the expectations and possibilities are during specific phases of the product release cycle.

Releases

All (since version 4.3.5) Liferay Portal CE releases are available at https://releases.liferay.com/portal/. Yes all, even those not meant for production use and those considered a “work in progress”. Below I will do my best to explain what is the purpose of different releases and how can you get involved.

Snapshots

Purpose: Mostly for internal purposes and provide immediate feedback to developers if the codebase is stable and likely to build.

How to recognize it: Snapshots are located in separate folder: https://releases.liferay.com/portal/snapshot-master/  

What feedback we expect: No feedback is expected in general. However sometimes specific feedback on specific features may be requested early and community members may be pointed here instead of waiting for a milestone.

How to provide feedback: Please do not send feedback for snapshot releases unless explicitly requested. If specific feedback has been requested please follow the instructions provided.

How to report bugs: Please do not report bugs for snapshots releases. Those are considered work in progress and are expected to contain bugs and unfinished / not working functionalities.

Milestone releases

Purpose: The earliest releases of any new version providing early preview of the new and updated features. Their purpose is to demonstrate the progress made and to make it possible to provide early feedback on specific features that are mature enough.

How to recognize it: The release version number ends with Mn where “n” is a number. For example “7.2.0 M2”.

What feedback we expect: Each milestone release is accompanied by a blog post, providing specific information about the features that are mature enough and ready to receive feedback. You are welcomed to provide feedback on other features but keep in mind they may be still work in progress.

How to provide feedback: Please send feedback by posting in “Feedback for Milestone releases” forum category.

How to report bugs: Please do not report bugs for milestone releases. Those are considered work in progress and are expected to contain bugs and unfinished / not working functionalities. If you feel the release has introduced a regression bug, please raise your concerns in “Feedback for Milestone releases” forum category.

Alpha releases

Purpose: The first releases to be tested. The product is not yet feature complete.

How to recognize it: The release version number ends with An where “n” is a number. For example “7.2.0 A1”.

What feedback we expect: At this point feedback on all features and functionalities is welcomed.  

How to provide feedback: Please send feedback by posting in “Feedback for Milestone releases” forum category.

How to report bugs: Please do not report bugs in new functionalities. Please report regression bugs in our issue tracking system. If unsure about the bug nature, please ask in “Feedback for Milestone releases”. Make sure to select the proper Alpha version. Please report bugs only related to the latest (at the time of reporting) Alpha version. Please do not report bugs in Alpha versions once Beta version is released.

Beta releases

Purpose: The first releases of a feature complete product. They may contain bugs and issues related to speed or performance.

How to recognize it: The release version number ends with Bn where “n” is a number. For example “7.2.0 B1”.

What feedback we expect: Feedback on all features and functionalities is welcomed. However as this is feature complete release, any feedback aiming to change or improve the features would be only considered for the next product version.

How to provide feedback: Please provide feedback in “Suggestions and Feature Requests”  forum category.

How to report bugs: Please report bugs in our issue tracking system. Make sure to select the proper Beta version. Please report bugs only related to the latest (at the time of reporting) Beta version. Please do not report bugs in Beta versions once RC version is released.

Release Candidate releases

Purpose: Beta versions with potential to be a final product.

How to recognize it: The release version number ends with RCn where “n” is a number. For example “7.2.0 RC1”.

What feedback we expect: Feedback on all features and functionalities is welcomed. However as this is feature complete release, any feedback aiming to change or improve the features would be only considered for the next product version.

How to provide feedback: Please provide feedback in “Suggestions and Feature Requests”  forum category.

How to report bugs: Please report bugs in our issue tracking system. Make sure to select the proper RC version. Please report bugs only related to the latest (at the time of reporting) RC version. Please do not report bugs in RC versions once GA version is released.

General Availability releases

Purpose: Stable, production ready product releases.

How to recognize it: The release version number ends with GAn where “n” is a number. For example “7.2.0 GA1”.

What feedback we expect: Feedback on all features and functionalities is welcomed. However as this is stable release, any feedback aiming to change or improve the features would be only considered for the next product version.

How to provide feedback: Please provide feedback in “Suggestions and Feature Requests”  forum category.

How to report bugs: Please report bugs in our issue tracking system. Make sure to select the proper GA version. Please report bugs only related to the latest (at the time of reporting) GA version. Please do not report bugs in GA versions after the version’s end of life.

How we process feedback and bug reports

Both feedback related forum categories and issue tracking system have process in place to notify respective teams. In addition Developer Relations team is also actively monitoring those, trying to help bridge the gap when needed and minimize the duplication of the reports. In other words, we do our best to read, verify and respond to everything you have to say. 

However we are all humans. Very busy humans in fact. So we may miss something or it sometimes may take a little longer than usual before you get a response. And yes, I'm aware of the amount of past feedback and reported issues are left without an answer. We have made our mistakes and we do learn from them. So if you feel your feedback or bug report is waiting too long, please send a friendly reminder in a form of new post, issue comment or an email to developer-relations@liferay.com 

Blogs

Hi Milen!

 

I feel that doing this probably wasn't a good idea. Basically what has happened is that you have killed a whole lot of potential feedback. The good thing about the beta-program was the information from you to us. The beta program helped us understand what you are working on, and what you are planning on changing at an early enough stage that we could provide feedback. But killing of the beta program and replacing it with radio silence, is basically killing of one of your better communication channels.

 

None of us are going to read the whole Jira-ticket lists to see what is changing. Only a very few people (whith to much time on their hands) are going to download a release candidate and randomly try to find out what has changed. 

 

What you need is a good, clear, and easy channel to communicate these things to us, in a way that I as a developer can understand them, but also, the end user, who would look at the Jira-list and not see anything other than giberish.

 

So if you do actually want feedback, don't kill of the one place we could determine what you need feedback on, and what we should start looking into to prepare for the future without providing an alternative.

Thank you Brendan Johan Lee!

 

You are right and I couldn't agree more with you, regarding the importance of the information flow from Liferay's product teams to the community members. You are wrong assuming that our intention is to kill it or "replace it with radio silence". It is quite the opposite in fact.

 

I am preparing another blog post to explain this in more details but essentially all Beta programs consisted of  3 main things: Announcements/Instructions,  Documentation and Forum discussions and all those are still available and will be available. For example, here is what is new in the Alpha 1 release: https://community.liferay.com/blogs/-/blogs/liferay-portal-7-2-ce-alpha-1-release. The 7.2 documentation needs some more work but hopefully it will be ready soon. And we do encourage everyone to contribute to the forum discussions. 

 

To the best of our knowledge, there is nothing that the new process makes impossible or harder than the one we used in the beta programs. That said, it may be the case that we missed something that was particularly important to you in the Beta program. If so, please let us know and we will do our beast to address the issue. Please email us (developer-relations@liferay.com) your concerns and suggestions. 

 

 

Hi Again Milen!

 

Was not my intention to imply that you were planning onreplacing it with radio silence. I know that you, Jamie (and previously James) have worked a lot on improving communications, and a lot of things have been improved (such as the dev site which has been  a _huge_ improvement).

 

However, your link to the blogpost illustrates my point exactly. I've not seen that blogpost. Why? Because I don't have time to read the blog all the time. That is something I get to do once in a blue moon when I have a bit of downtime. The beta testing sites on the other hand, I was always active on, and actively both following and contributing. Why? Beacuse they were directly important for my job. 

 

My point here is rather that you are moving away from a nice distilled single point of access for everything about a coming upgrade, to having all of the information spread out across many different places, ranomly mixed in among all sorts of other information. That makes things much more complicated for us. And in the end leads to us having to invest much more effort to actually provide feedback. This is bad.

 

Now. If everything about a future release was distilled and provided nicely in one place, I would be happy. It can be as simple as a single page with links to the documentation, blog posts about the new features, any discussions in the forum, and potentially also slack, and a mechanism to subscribe to changes to the page,  that would be a fine replacement.

 

A different way of seeing it: With the beta program, I had a single place, where I passively could receive any relevant information about an upcoming release (by for example subrscribing to topics), and provide feedback in the same single point of access. This has now changed, and the only way to stay updated is to continuously _actively_ seek out information, which in my opinion is a big step backwards.

Hi Milen,

 

I had to agree with Brendan. But I think it's not only related to the beta program. Instead I think sth. changed from 5.x to 6.x in the way how Liferay respond to contributions of any kind. I've started back in the days of 5.2.x. There it was common to "meet" Liferay devs in the forum for questions, bugs, contributions etc. Nowadays it seems -I had to quote Brendan- "radio silence".

 

A few examples:

- Last year I've encountered a bug, asked in the forum and didn't get any response until today

- I've created a bug ticket in may 2018 (LPS-80504) and didn't get any response even though I've provided details + a workaround

- I would have liked to contribute a webcontent preview feature (LPS-57016 / LPS-15096) which also gets the attention of some Liferay devs who liked it. I've improved the first solution (5.2.3) a lot and migrated it for 6.2. This ticket is older than 3 years and still no one from Liferay accepted or declined it.

 

I don't have that much time besides the daily work. But still I like to contribute as you can see e.g. https://web.liferay.com/de/community/special-projects/top-contributor-awards-2013. I don't mind if the Liferay devs don't like each one of my ideas :). But don't getting ANY response over years is very discouraging for contributing in the future.

 

Maybe it sounds too harsh which wasn't the intention at all :). It's just because I like the open-source idea of contributing and at the same time Liferay is giving us a hard time ...

Hopefully it will change over the next months / years.

Hi Brendan Johan Lee and Oliver Bayer

 

I see your point and I understand the need to have all the information grouped in a single, well known place. That said, the way we were doing it with the Beta program was far from optimal. It was very time consuming to prepare the program, it came vary late in the game (as a result a lot of feedback was not taken into account) and it introduced information fragmentation between the "regular" and the "beta" feedback channels. 

 

The change I talk about above is an attempt to solve those issues but you are right, it caused us to lose the central place of information grouping. That is not meant to stay that way though. So please, think of the current situation as a transition phase. I don't want to make any premature promises yet, but I can assure you we are spending significant amount of time working on something that will allow us to better group and present the information in specific context, that will not suffer from the fragmentation and time constraints the Beta program had. 

 

 

Hey Milen,

 

it's been 4 months since you've announced the "new big thing" for contributions of all kind. As said it's not just the beta program which is affected.  Do you made any progress in this regard? I can't see much improvement e.g. in the response time to tickets or mails until now ;).

Hey Oliver, The changes I was talking about were regarding the need to have all the information grouped in a single, well known place and making it clear how the release, feedback and contribution processes work  together. I think we managed to improve that with the new site. I'm writing a blog about it with more details. What you are talking about is issues with how those process work (or don't) in practice. And I agree with you this needs to be improved and we as company should stick to our commitments to the Open Source community and treat contributors better. Sadly this is easier said than done and requires cross-department changes  that are way beyond the DevRel  team's competence. As comments to a blog post a hardly the best place to discuss this, I would like to ask you (and everyone else who have similar feelings) to summarize your experience (the one you mentioned above plus most recent one) in an email to developer-relations@liferay.com I promise you to look into each of those cases and bring them to the attention to the people who are in a position to execute on such feedback.