Wayne, you asked for ideas for improvement. My proposal to get possibly simpler text style and higher acceptance would be to turn the handbook into a Markdown-Encoded Github projects. So everybody can post PRs and your team can review these. People feel more bound to projects that show agile adoption of their input. :-) -Markus From: ee4j-pmc-bounces@xxxxxxxxxxx [mailto:ee4j-pmc-bounces@xxxxxxxxxxx] On Behalf Of Wayne Beaton
Sent: Donnerstag, 15. November 2018 18:16
To: Bill Shannon
Cc: EE4J PMC Discussions
Subject: Re: [ee4j-pmc] ACTION: Release Reviews I assure you that it is fully apparent to me that our processes are foreign to many of our new committers. The handbook is intended to be used a reference. I accept that it's not great prose and that it is unlikely that anybody knows the document as well as I do. I believe that my team presents it as reference material. We've put a lot of energy into making this as much of a "one-stop" reference guide as possible and will continue to evolve the content as we discover deficiencies or opportunities for improvement. I rarely point to the handbook in whole. The document is rendered to make it super easy to get links to specific sections (all headings are clickable links to themselves). I consider all anchors to be API and take great care to avoid changing them. I strongly encourage my team to provide pointers to relevant sections of the document in their responses to questions. Beyond focusing attention on specific sections of the document, I don't know how to address the general problem of folks not having time enough to read the documentation. I do understand that my writing style can be a bit verbose, but I do try to keep this content as concise as possible (while balancing the need for precision). If there are specific things that I can do to improve the documentation, I would appreciate the feedback. We have explored other ways of demystifying the EDP, including webinars and EclipseCon sessions. I am open to other ideas. Having said all that, your feedback regarding the implementation of the creation pages is noted and appreciated. I have created a Bugzilla record to track the requirement. Maybe it's not apparent to you, but many people are just not going to read the handbook from beginning to end (although I've tried), and a recommendation to read it while in the middle of trying to get something done is likely to be ignored.
I've already forgotten what the differences were between the "create a release" page and the "create a review" page. At least one of them allowed me to select any date after today. But to do a release I need to complete a release review before then, and I need to complete IP review before that, and the release review has to be synchronized to twice a month. None of that was apparent on any of the pages as I remember. Yes, maybe if I read the entire handbook I would only use the creation pages in safe manner. If the pages can't enforce these constraints for me, they should at least explain the constraints so I can use the pages effectively.
So, explaining the synchronization requirements and the lead time requirements on the creation pages would be a good start.
Thanks.
Wayne Beaton wrote on 11/12/18 12:51 PM: The "create a release" page includes a link to the documentation (although it's an old link) with a request that you "Please review the release cycle documentation." The "create a review" page only lets you select valid review dates. It's all captured in the handbook, which includes this passage (along with a pretty complete overview of what's required): We schedule reviews to conclude on the first and third Wednesdays of the month. Your release date does not have to coincide with the review date (you can set the release date as necessary). The review must, however, conclude successfully before you can make the release official.
What, specifically, would like to see added or changed? I'm still learning about all the timing requirements related to these release reviews. When I submitted my recent release reviews, it only said I needed to allow one week for community review. It didn't say anything about needing to synchronize with some twice monthly event.
It also wanted another week for IP review, but that wasn't apparent until after I submitted the release review.
Can someone summarize the actual requirements, and maybe get them added to the release review creation page where it asks you to supply a date?
Thanks. Kevin Sutter wrote on 11/02/2018 06:00 AM: Another bit of advice... Currently, the Eclipse Release Reviews are only on the first and third Wednesdays of the month. That means, Nov 7 and 21. Very few projects will be ready by the 7th, so that means a huge backlog of release reviews on the 21st... Unless... I seem to remember Wayne possibly proposing some additional release reviews during this initial hectic time period. Wayne, any thoughts on that idea? With the push to be done by the end of the month, there's going to be a ton of release reviews requested this month.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>
To: EE4J PMC Discussions <ee4j-pmc@xxxxxxxxxxx>
Date: 11/02/2018 04:54 AM
Subject: Re: [ee4j-pmc] ACTION: Release Reviews
Sent by: ee4j-pmc-bounces@xxxxxxxxxxx
Yes. The release content should be in a "release candidate" form prior to engaging in the release review.
Wayne
On Fri, Nov 2, 2018, 05:42 Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx wrote:
Question on timing from my team. Do they have to update to Jakarta released artifacts before release review?
From: ee4j-pmc-bounces@xxxxxxxxxxx<ee4j-pmc-bounces@xxxxxxxxxxx> On Behalf Of Dmitry Kornilov
Sent: 01 November 2018 15:26
To: EE4J PMC Discussions <ee4j-pmc@xxxxxxxxxxx>
Subject: [ee4j-pmc] ACTION: Release Reviews Hi, According to GlassFish 5.1 release plan each project has to pass the release review before Nov 30th. In order to meet this deadline I am strongly suggesting initiating the release review process as soon as possible. Release review how-to guide is a part of this article. Please update Release Review Tracker page when the review is initiated or completed . Thanks, Dmitry
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________ ee4j-pmc mailing list ee4j-pmc@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
-- Wayne Beaton Director of Open Source Projects | Eclipse Foundation, Inc. Meet us at EclipseCon Europe 2018: LUDWIGSBURG, OCTOBER 23 - 25 _______________________________________________ ee4j-pmc mailing list ee4j-pmc@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ee4j-pmc
-- Wayne Beaton Director of Open Source Projects | Eclipse Foundation, Inc. Meet us at EclipseCon Europe 2018: LUDWIGSBURG, OCTOBER 23 - 25 |
