Well, I believe he was hinting at that a docking framework is considered more complex, there was no negative sentiment in that. Although I do not think a docking framework is that complex, but maybe I'm wrong.
And yes, ALMOST everyone is at ControlFX ;-) > Jonathan - why do you *cough* at ideas like more complex controls and > docking frameworks? > > I think that a docking framework especially would be a great addition to > JavaFX. > > Am I missing something? > >> On 7 Feb 2018, at 18:16, Jonathan Giles <jonat...@jonathangiles.net> >> wrote: >> >> Obviously everyone is at ControlsFX instead ;-) >> >> Part of the drop I would suggest is simply that many of the itches >> people >> want to scratch are now scratched. Alternatively, the remaining itches >> are >> either in more complex controls (*cough* docking frameworks *cough*) or >> in >> areas beneath the controls APIs - performance, webview, etc - which are >> more challenging and require greater levels of dedication. >> >> However, more generally, your point is well made - contribution to >> JavaFX >> does not need to be synonymous with contribution to OpenJFX. People who >> find the challenges of the current OpenJFX requirements too great should >> be >> encouraged to involve themselves in projects such as JFXtras, etc. >> >> -- Jonathan >> >>> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink <t...@tbee.org> wrote: >>> >>> Many years ago I had a discussion with Jonathan Giles about if the >>> things >>> that were being made in JFXtras would eventually become part of the >>> JavaFX >>> core. In the end I decided that, for me personally, I could do the >>> things I >>> wanted to perfectly in a separate project. The rigid structure that >>> Java(FX) has to adhere to, would be a big downside. >>> >>> What I want to say with that is that all the external projects are also >>> contributions to JavaFX. It does not matter whether for example a >>> control >>> is part of the core distribution or of a side project; it is just >>> another >>> module users can add to the mix. >>> >>> So reflecting back I still stand by that choice. But having a few more >>> people in the project (just like in JavaFX ;-) ) would be nice, but >>> OTOH it >>> forces me to deal with (and learn about) annoying stuff like Gradle >>> build >>> scripts and Java 9 migration. But because of that progress is not as >>> fast >>> as I would like it to be. Could it be that there is a decline in people >>> willing to work for open source projects? Or is it just that this tech, >>> JavaFX, is no longer appealing? >>> >>> Tom >>> >>> >>> >> Obviously everyone is at ControlsFX instead ;-) >> >> Part of the drop I would suggest is simply that many of the itches >> people >> want to scratch are now scratched. Alternatively, the remaining itches >> are >> either in more complex controls (*cough* docking frameworks *cough*) or >> in >> areas beneath the controls APIs - performance, webview, etc - which are >> more challenging and require greater levels of dedication. >> >> However, more generally, your point is well made - contribution to >> JavaFX >> does not need to be synonymous with contribution to OpenJFX. People who >> find the challenges of the current OpenJFX requirements too great should >> be >> encouraged to involve themselves in projects such as JFXtras, etc. >> >> -- Jonathan >> >>> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink <t...@tbee.org> wrote: >>> >>> Many years ago I had a discussion with Jonathan Giles about if the >>> things >>> that were being made in JFXtras would eventually become part of the >>> JavaFX >>> core. In the end I decided that, for me personally, I could do the >>> things I >>> wanted to perfectly in a separate project. The rigid structure that >>> Java(FX) has to adhere to, would be a big downside. >>> >>> What I want to say with that is that all the external projects are also >>> contributions to JavaFX. It does not matter whether for example a >>> control >>> is part of the core distribution or of a side project; it is just >>> another >>> module users can add to the mix. >>> >>> So reflecting back I still stand by that choice. But having a few more >>> people in the project (just like in JavaFX ;-) ) would be nice, but >>> OTOH it >>> forces me to deal with (and learn about) annoying stuff like Gradle >>> build >>> scripts and Java 9 migration. But because of that progress is not as >>> fast >>> as I would like it to be. Could it be that there is a decline in people >>> willing to work for open source projects? Or is it just that this tech, >>> JavaFX, is no longer appealing? >>> >>> Tom >>> >>> >>> >>>> On 7-2-2018 03:16, Kevin Rushforth wrote: >>>> >>>> I would recommend against having a separate issue tracker or mailing >>>> list >>>> associated with the sandbox. That will create more confusion than any >>>> benefit you might have. >>>> >>>> -- Kevin >>>> >>>> >>>> Nir Lisker wrote: >>>> >>>>> Another thing to be careful about with the sandbox/staging idea is >>>>> the >>>>> confusion that will arise with duplication. There will be 2 issue >>>>> trackers >>>>> (JBS and GitHub (or GitHub-like)), 2 repo addresses, 2 wikis, and >>>>> maybe 2 >>>>> discussion lists. For those "in the know" this will be a simple >>>>> matter, but >>>>> for a potential contributor this can be a gamebreaker if not handled >>>>> appropriately. >>>>> >>>>> Dalibor Topic's suggestion of contacting other mirrors can be >>>>> instrumental in solving these problems. >>>>> >>>>> - Nir >>>>> >>>>> On Mon, Feb 5, 2018 at 4:41 PM, Kevin Rushforth < >>>>> kevin.rushfo...@oracle.com <mailto:kevin.rushfo...@oracle.com>> >>>>> wrote: >>>>> >>>>> Yes, this sounds like a good step in the right direction. This >>>>> would give anyone (with a signed OCA) the ability to create their >>>>> own branch, commit changes to it, submit a PR, etc. >>>>> >>>>> I presume there will be a branch that is an exact mirror of the >>>>> jfx-dev repo on OpenJDK in addition to the development branch in >>>>> the sandbox? >>>>> >>>>> The only thing to consider is whether it should be Committers or >>>>> Reviewers that have rights to merge into the sandbox development >>>>> branch. There are pros / cons of each. I'd probably lean towards >>>>> having it be Committers, with the idea that a Committer needs to >>>>> sponsor the patch anyway and would then be able to "take it the >>>>> rest of the way". The only downside I see is that you could end up >>>>> with a few patches that get accepted into the sandbox dev branch, >>>>> but never make it to the upstream jfx-dev repo (or not without >>>>> significant change). I doubt this will be a big problem in >>>>> practice. >>>>> >>>>> Either way, this could also provide a good alternative to webrev >>>>> when reviewing the final changes. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> >>>>> Johan Vos wrote: >>>>> >>>>> Hi Michael, >>>>> >>>>> This proposal is very much in line with my thinking as well. >>>>> The problem is not that we don't have a github clone of >>>>> OpenJFX. We have a >>>>> number of them (e.g. I created >>>>> https://github.com/javafxports/jfx-dev >>>>> <https://github.com/javafxports/jfx-dev> some >>>>> months ago). We just need a single one that is updated >>>>> constantly from >>>>> mainstream, and standardize on that. Let's call that "sandbox" >>>>> (I would be >>>>> ok with staging as well, but sandbox is imho more inviting to >>>>> people who >>>>> want to try something drastic, e.g. support for Vulkan) >>>>> >>>>> The main issue is how to get contributions, review them, and >>>>> eventually >>>>> send them upstream. >>>>> >>>>> The PR review process is extremely important. If we lower that >>>>> bar, we >>>>> loose quality. If the bar is too high, great PR's won't be >>>>> accepted >>>>> upstream as there is not enough review time to review it. >>>>> >>>>> I agree giving the current OpenJFX committers merge rights for >>>>> the >>>>> "sandbox" repository makes sense. Once a public contribution >>>>> is merged by >>>>> one of those committers, that same committer can send it >>>>> upstream to the >>>>> existing OpenJFX repository. Additional checks will be >>>>> performed there, >>>>> mainly in order to make sure the overall "Feel of Java" is >>>>> preserved. To >>>>> that purpose, it would help to have a closer alignment with >>>>> the OpenJDK >>>>> community. >>>>> >>>>> We have to be aware that this will increase the workload of >>>>> the current >>>>> committers and reviewers. That is the price we pay for >>>>> standardization. >>>>> Rather than everyone creating his own forks of a UI framework >>>>> in Java, we >>>>> invest a lot in creating a single, generally agreed one. >>>>> >>>>> So in summary, I'm +1 on a 2-phase approach: "open" commits >>>>> allowed in >>>>> staging. OpenJFX committers accept PR's (if they are of good >>>>> quality) and >>>>> prepare upstream commits for OpenJFX. We hope there will be >>>>> more >>>>> contributors who become committers and reviewers in the medium >>>>> term. >>>>> >>>>> - Johan >>>>> >>>>> On Mon, Feb 5, 2018 at 3:57 AM Michael Ennen >>>>> <mike.en...@gmail.com <mailto:mike.en...@gmail.com>> wrote: >>>>> >>>>> >>>>> Those are great questions, and I think with >>>>> Kevin/Oracle/other OpenJFX devs >>>>> help we >>>>> can figure something out. >>>>> >>>>> My thinking is that the PR would be reviewed by basically >>>>> anyone who has >>>>> free time. >>>>> I think that, at first, only OpenJFX committers will be >>>>> able to merge PRs. >>>>> They would >>>>> do the final review/merge to the staging repo after it has >>>>> been reviewed by >>>>> the "wider audience" >>>>> which includes people without commit rights (people like >>>>> us). Then, as this >>>>> thing evolves, >>>>> based on the pool of people who are contributing both pull >>>>> requests and PR >>>>> reviews, >>>>> the committers will be able to grant commit privileges to >>>>> some people in >>>>> that pool. >>>>> >>>>> I can't think of any way that would make it so the changes >>>>> are as likely to >>>>> be >>>>> merged upstream as possible other than having the current >>>>> OpenJFX >>>>> committers paving the >>>>> way. Hopefully this vision is aligned with Kevin's and >>>>> hopefully these >>>>> concrete details >>>>> can be worked out. >>>>> >>>>> Regards, >>>>> Michael >>>>> >>>>> On Sun, Feb 4, 2018 at 6:21 PM, Nir Lisker >>>>> <nlis...@gmail.com <mailto:nlis...@gmail.com>> wrote: >>>>> >>>>> >>>>> So if a community ran GitHub is used for staging, who >>>>> will approve PRs >>>>> >>>>> for >>>>> >>>>> the code and the Wiki of the GitHub repo? >>>>> >>>>> On Mon, Feb 5, 2018 at 2:40 AM, Michael Ennen >>>>> <mike.en...@gmail.com <mailto:mike.en...@gmail.com>> >>>>> wrote: >>>>> >>>>> >>>>> Great points, Nir. We share the same hopes. I just >>>>> wanted to piggy-back >>>>> on the >>>>> wiki thing: >>>>> >>>>> " * The Wiki could be open sourced as well (like >>>>> other Wikis). I could >>>>> definitely update a page or 2 there and so would >>>>> other developers as >>>>> >>>>> they >>>>> >>>>> gain knowledge. I don't know yet how permissions >>>>> for that should be >>>>> handled." >>>>> >>>>> This is another thing that we could use the GitHub >>>>> staging repository >>>>> >>>>> for. >>>>> >>>>> The staging repository could have a wiki (projects >>>>> on GitHub can have >>>>> >>>>> one) >>>>> >>>>> that is editable by all, and then maybe once a >>>>> month or so someone with >>>>> permissions >>>>> to edit to official wiki can sync with the new, >>>>> reviewed changes (the >>>>> once-a-month >>>>> time constraint is very flexible). >>>>> >>>>> I am just trying to explain how the GitHub >>>>> repository "one-way mirror" >>>>> (potentially linked >>>>> with/managed by Adopt an OpenJDK) can act as a >>>>> staging ground for all >>>>> kinds of contributions to >>>>> OpenJFX. >>>>> >>>>> By the way, I am trying to cleanup the groundwork >>>>> I did on getting >>>>> Appveyor builds to >>>>> run for openjfx, if indeed it is decided to setup >>>>> such a staging >>>>> repository. You can >>>>> see my efforts here: >>>>> https://raw.githubusercontent. >>>>> >>>>> >>>>> com/brcolow/openjfx/f1b8978849fc371683b40931c17020421acc0057 >>>>> /appveyor.yml >>>>> >>>>> If the GitHub repository was setup, changes such >>>>> as these to add CI >>>>> infrastructure would >>>>> never be adopted by upstream OpenJFX, but would >>>>> allow for developer's to >>>>> get good >>>>> feedback on test results for all supported >>>>> platforms when they open a >>>>> >>>>> PR. >>>>> >>>>> Merging a PR >>>>> on the public GitHub repository means, in my >>>>> opinion, that it is ready >>>>> >>>>> to >>>>> >>>>> be opened as >>>>> an upstream bug/feature request. Automating the >>>>> process with patch sets, >>>>> webrevs, formatting/lint >>>>> results, etc. would be the most ideal situation >>>>> and I would be happy to >>>>> contribute to these >>>>> efforts. >>>>> >>>>> Regards, >>>>> >>>>> Michael Ennen >>>>> >>>>> >>>>> >>>>> On Sun, Feb 4, 2018 at 5:29 PM, Nir Lisker >>>>> <nlis...@gmail.com <mailto:nlis...@gmail.com>> >>>>> wrote: >>>>> >>>>> >>>>> Hello, >>>>> >>>>> As someone who has recently made the climb and >>>>> managed to build OpenJFX >>>>> with OpenJDK on Win 10 I might have some >>>>> relevant input. >>>>> >>>>> --- Building OpenJFX --- >>>>> >>>>> * With the recently updated instructions on >>>>> the Wiki, building OpenJFX >>>>> >>>>> is >>>>> >>>>> not that hard. Having to build OpenJDK for >>>>> that was a real headache >>>>> because >>>>> their instructions and build tools are not up >>>>> to date ( >>>>> https://bugs.openjdk.java.net/browse/JDK-8194645 >>>>> <https://bugs.openjdk.java.net/browse/JDK-8194645>). >>>>> * The above doesn't mean that the process >>>>> shouldn't be made easier. >>>>> Ideally, it would be the as easy as working on >>>>> most open source >>>>> >>>>> projects >>>>> >>>>> on >>>>> Github (not advocating git over hg): clone >>>>> into the IDE and start >>>>> working; >>>>> when a fix is ready, submit a PR. Don't know >>>>> if it's technically >>>>> >>>>> possible >>>>> >>>>> in this case, but it's a target. >>>>> * The repository needs a good cleanup before >>>>> contributors start >>>>> >>>>> cloning ( >>>>> >>>>> bugs.openjdk.java.net/browse/JDK-8196198 >>>>> <http://bugs.openjdk.java.net/browse/JDK-8196198>). >>>>> >>>>> --- Working on OpenJFX --- >>>>> >>>>> * It should be clear which tests need to run >>>>> for a specific patch. >>>>> Changes >>>>> can be made anywhere from the documentation >>>>> level to native code level >>>>> and >>>>> there's no reason to run the same tests for >>>>> all of these. If the >>>>> >>>>> process >>>>> >>>>> can be automate it's even better. >>>>> * The Webrev tool seems archaic to me (and >>>>> part of its output is broken >>>>> as >>>>> far as I could tell). An IDE can create diff >>>>> patches with a couple of >>>>> clicks. >>>>> * The Jcheck tool seems archaic to me. It >>>>> should be ported to IDE >>>>> formatters which are to be distributed with >>>>> the source. No reason to >>>>> >>>>> run >>>>> >>>>> a >>>>> tool that tells me which whitespaces I need to >>>>> go back and change when >>>>> something like Ctrl+Shift+F in an IDE finishes >>>>> the job. >>>>> >>>>> --- Wiki --- >>>>> >>>>> * The Wiki could be open sourced as well (like >>>>> other Wikis). I could >>>>> definitely update a page or 2 there and so >>>>> would other developers as >>>>> >>>>> they >>>>> >>>>> gain knowledge. I don't know yet how >>>>> permissions for that should be >>>>> handled. >>>>> * Code conventions should be clearly listed. >>>>> * Separate sections with instructions should >>>>> be made for: (1) cloning >>>>> >>>>> and >>>>> >>>>> building, (2) modifying, (3) running tests, >>>>> (4) submitting, and (5) >>>>> reviewing. >>>>> * Old sections should be cleaned up (I don't >>>>> think Discussions is >>>>> >>>>> useful >>>>> >>>>> anymore). >>>>> >>>>> --- Review policy --- >>>>> >>>>> * I have no experience with review policies or >>>>> project roles so I can't >>>>> help here much (maybe after a discussion >>>>> starts). >>>>> * One thing I do know is that reviewers should >>>>> be extremely >>>>> knowledgeable, >>>>> which means that there aren't many qualified. >>>>> Because of this, if it >>>>> becomes "too" easy to contribute to OpenJFX, >>>>> careful measures need to >>>>> >>>>> be >>>>> >>>>> taken as to not to swamp the few reviewers >>>>> with many patches (though >>>>> >>>>> some >>>>> >>>>> would say this is an ideal situation). Some >>>>> sort of review queue might >>>>> help >>>>> with organization instead of the current email >>>>> system. I have no >>>>> >>>>> concrete >>>>> >>>>> solution for this. >>>>> >>>>> - Nir >>>>> >>>>> >>>>> Message: 1 >>>>> >>>>> Date: Thu, 01 Feb 2018 15:26:24 -0800 >>>>> From: Kevin Rushforth >>>>> <kevin.rushfo...@oracle.com >>>>> <mailto:kevin.rushfo...@oracle.com>> >>>>> To: "openjfx-dev@openjdk.java.net >>>>> <mailto:openjfx-dev@openjdk.java.net>" >>>>> <openjfx-dev@openjdk.java.net >>>>> <mailto:openjfx-dev@openjdk.java.net>> >>>>> Subject: More community participation in >>>>> JavaFX >>>>> Message-ID: <5a73a220.7030...@oracle.com >>>>> <mailto:5a73a220.7030...@oracle.com>> >>>>> Content-Type: text/plain; >>>>> charset=windows-1252; format=flowed >>>>> >>>>> To: OpenJFX Developers >>>>> >>>>> We are looking to grow the community of >>>>> contributors to the OpenJFX >>>>> project, especially serious contributors >>>>> who will stick around long >>>>> enough to become reviewers, to help us >>>>> keep the platform vibrant. To >>>>> this end we are looking at ways to >>>>> encourage more participation and >>>>> >>>>> make >>>>> >>>>> it easier for interested folks to >>>>> contribute. >>>>> >>>>> We are specifically looking to discuss >>>>> ideas around the following >>>>> >>>>> areas: >>>>> >>>>> * Easing barriers to contribution (e.g., >>>>> making JavaFX easier to >>>>> >>>>> build, >>>>> >>>>> better documentation, making it easier to >>>>> test changes) >>>>> >>>>> * Code review policies >>>>> >>>>> * API / feature review policies >>>>> >>>>> * Code review tools (we currently use >>>>> webrev, but that isn't set in >>>>> >>>>> stone) >>>>> >>>>> To keep this thread productive, the >>>>> following are explicitly out of >>>>> >>>>> scope: >>>>> >>>>> * Discussion of specific features or bugs >>>>> that you would like to >>>>> implement (or wish someone else would) >>>>> >>>>> * Discussion about platform support >>>>> >>>>> * Discussion about version control systems >>>>> (e.g., hg versus git), >>>>> hosting of the OpenJFX repos and bug >>>>> database (e.g., OpenJDK versus >>>>> github), etc...at least for now. We are >>>>> aware of the potential >>>>> >>>>> benefits >>>>> >>>>> of such changes, but we'd like to focus >>>>> our efforts on >>>>> >>>>> higher-leverage >>>>> >>>>> things we can do in the short term. >>>>> >>>>> * Discussion about the requirement of a >>>>> signed OCA to become a >>>>> >>>>> contributor >>>>> >>>>> * Off-topic or tangential commentary about >>>>> OpenJFX that isn't >>>>> >>>>> directly >>>>> >>>>> related to the topic at hand >>>>> >>>>> >>>>> As a starting point for discussion, here >>>>> are some areas I think need >>>>> improvement; I'm sure there are others: >>>>> >>>>> I. Helping contributors get started >>>>> >>>>> It isn?t as easy to get started with >>>>> OpenJFX as it should be. We want >>>>> >>>>> to >>>>> >>>>> make it easier for potential OpenJFX >>>>> contributors to get started. >>>>> >>>>> Here >>>>> >>>>> are some ideas that I think might help: >>>>> >>>>> * Improve the build instructions / Wiki (I >>>>> made a first start, but >>>>> >>>>> there >>>>> >>>>> is much more to be done) >>>>> >>>>> * Make the build itself more resilient >>>>> where possible, and provide >>>>> better error messages, specifically when >>>>> dealing with native >>>>> >>>>> compilers >>>>> >>>>> and libraries >>>>> >>>>> * Add an option to skip building all >>>>> native code and use prebuilt >>>>> binaries (like we do already for media and >>>>> webkit); this is tracked >>>>> >>>>> by >>>>> >>>>> JDK-8092279, but it hasn?t been looked at >>>>> recently >>>>> >>>>> * Make it easier to build / test your >>>>> local OpenJFX build using an >>>>> OpenJDK build (currently the only way to >>>>> do this is to build OpenJDK >>>>> locally, after using configure to point to >>>>> your just-built javafx.* >>>>> modules). >>>>> >>>>> * Provide step-by-step instructions for >>>>> how to make a contribution, >>>>> including testing requirements; a lot of >>>>> the pieces are there, but >>>>> >>>>> are >>>>> >>>>> out of date or scattered in several >>>>> places. As part of this, we could >>>>> have a section on how to contribute docs, >>>>> samples or tests, since >>>>> >>>>> that >>>>> >>>>> is often a good place to start. >>>>> >>>>> * Provide a sandbox environment where >>>>> contributors can discuss and >>>>> >>>>> test >>>>> >>>>> ideas. For example, an OpenJFX mirror on >>>>> github, potentially >>>>> >>>>> connected >>>>> >>>>> to AdoptOpenJDK. >>>>> >>>>> >>>>> II. Code reviews and API reviews >>>>> >>>>> Code reviews are important to maintain >>>>> high-quality contributions, >>>>> >>>>> but >>>>> >>>>> we recognize that not every type of change >>>>> needs the same level of >>>>> review. Without lowering our standards of >>>>> quality, we want to make it >>>>> easier to get low-impact changes (simple >>>>> bug fixes) accepted. >>>>> >>>>> There are three categories of changes, >>>>> each of which might merit a >>>>> different review standard: >>>>> >>>>> 1. Low-impact bug fixes. These are >>>>> typically isolated bug fixes with >>>>> little or no impact beyond fixing the bug >>>>> in question; included in >>>>> >>>>> this >>>>> >>>>> category are test fixes (including new >>>>> tests) doc fixes, and fixes to >>>>> sample applications (including new >>>>> samples). >>>>> >>>>> 2. Higher impact bug fixes or RFEs. These >>>>> include changes to the >>>>> implementation that potentially have a >>>>> performance or behavioral >>>>> >>>>> impact, >>>>> >>>>> or are otherwise broad in scope. Some >>>>> larger bug fixes will fall into >>>>> this category, as will fixes in high-risk >>>>> areas (e.g., CSS). >>>>> >>>>> 3. New features / API additions. In >>>>> addition to reviewing the >>>>> implementation, we will need a separate >>>>> approval process for the new >>>>> >>>>> API >>>>> >>>>> / feature (such as the CSR, which is what >>>>> we use now, or a similar >>>>> process). >>>>> >>>>> We take compatibility seriously, so >>>>> anything that adds new API needs >>>>> >>>>> to >>>>> >>>>> be done with an eye towards supporting it >>>>> for at least 10 years. We >>>>> don't want to add new public API without >>>>> that level of commitment. >>>>> >>>>> Every >>>>> >>>>> new feature forecloses on alternate future >>>>> features. Significant >>>>> >>>>> effort >>>>> >>>>> must be taken to think about "if we did >>>>> this, what could it interact >>>>> with in the future?" Also, anything with a >>>>> large potential impact on >>>>> performance or behavioral compatibility >>>>> needs to be looked at >>>>> >>>>> carefully. >>>>> >>>>> Put another way, we want to encourage >>>>> thinking about new features or >>>>> >>>>> new >>>>> >>>>> API in terms of a design / stewardship >>>>> process; to think in terms of >>>>> questions like "what's the right thing for >>>>> JavaFX in the next 10+ >>>>> >>>>> years" >>>>> >>>>> rather than "here's some code that solves >>>>> my problem, please take >>>>> >>>>> it". >>>>> >>>>> As a stake in the ground, I might suggest >>>>> the following: >>>>> >>>>> * All changes need at least one reviewer >>>>> other than the person making >>>>> the change who can evaluate the change for >>>>> correctness and >>>>> >>>>> consistency. >>>>> >>>>> For simple bug fixes, a single reviewer >>>>> may be sufficient. Of course, >>>>> one of our big challenges in all this is: >>>>> "how do we grow more >>>>> reviewers?", by which I mean "how do we >>>>> facilitate getting >>>>> >>>>> contributors >>>>> >>>>> with enough expertise in a given area to >>>>> eventually be able to >>>>> effectively review contributions from >>>>> others?" >>>>> >>>>> * We need clear criteria for the other two >>>>> categories that balance >>>>> process efficiency with the desire to >>>>> maintain compatibility and >>>>> stability. API changes need to be approved >>>>> by a lead. My thought is >>>>> >>>>> to >>>>> >>>>> combine the last two into a single >>>>> category for purposes of reviewing >>>>> the implementation. Anything that affects >>>>> public API or behavioral >>>>> compatibility will require CSR or similar >>>>> approval, over and above >>>>> >>>>> the >>>>> >>>>> implementation review, which seems >>>>> sufficient. >>>>> >>>>> * I recommend that we formalize the >>>>> concept of reviewers, using the >>>>> OpenJDK Reviewer role for the Project. We >>>>> might also consider if we >>>>> >>>>> want >>>>> >>>>> to make any changes to the criteria used >>>>> by the JDK Project for >>>>> >>>>> becoming >>>>> >>>>> an OpenJFX Project Author, Committer, and >>>>> Reviewer. The OpenJDK >>>>> >>>>> bylaws >>>>> >>>>> allow projects a fair degree of latitude >>>>> to define these criteria, so >>>>> >>>>> we >>>>> >>>>> might consider making some modifications. >>>>> For example, we might make >>>>> >>>>> it >>>>> >>>>> somewhat easier for a Contributor to >>>>> become an Author, or for a >>>>> Committer to become a Reviewer. I have >>>>> some thoughts on this, but >>>>> >>>>> want >>>>> >>>>> to hear from others first. >>>>> >>>>> >>>>> I look forward to feedback on this >>>>> proposal, and hope it will spark a >>>>> productive discussion. >>>>> >>>>> -- Kevin Rushforth, OpenJFX Project Lead >>>>> >>>>> >>>>> >>>>> >>>>> >>> >
