Replies: 1 comment 4 replies
-
|
I'm excited with this release, many good stuff... Some I have being waiting for years! However, I would like to point that PR's should have more enforcement on description. <!--
We don't want to call the expensive Filter() as user types in,
it will lag the interface, instead give it a debounce time of 500ms between changes
!-->
<TextBox Watermark="Search filter" Text="{Binding FilterText, Delay=500}" />This stated, I think it's important to enforce useful PR descriptions, like, what it addresses and how to use. If author fails to, the team should ask for completion in behalf of readers. I think this would heavy benefit everyone. |
Beta Was this translation helpful? Give feedback.
-
|
The new property is documented in the source code, and once the changes are released the text will appear in the API reference documentation. Using PRs as documentation is the problem here. A PR is an event at a point in time, and shouldn't be used to determine the current state of the repository or API. Even if written to perfection a PR description can go stale at any point, sometimes even while the PR is still open. |
Beta Was this translation helpful? Give feedback.
-
Exactly the point, in this case we need to explore the source to know basic information about the PR, which can be easily missed in a huge codebase. If we need to explore the commit to understand the PR the description falied.
We don't want PRs as documentation that would be ugly... We want PR documented.
True and true. But that said should we start now issuing PR with blank descriptions as possible just because the fact they can stale at any time (if any)? When we open an PR/issue we know that's an event in time. PR description can go stale compared to master/main/other PR, BUT never with itself! Which is the point, when I open a PR to read, I expect to know about that exact PR and no other PR nor master. Let's not get excuses to not make it right, there are git good practices and rules that should be followed, this project should have more restriction due its nature, user base and size. Back to my examples...
So far, I only spoke about the bad examples but let me give a good one Feature - Container Queries.
Imagine if he copied same description... Same terror as [AssignBinding]. I stated that PRs should not be documentation but documented and I will stand this forever. However, let's be honest here, the xml documentation in the API reference documentation is ok for something like Me included, jump right away to this release, because it brings soo many goodies that we were waiting for long, a real quality of improvement upgrade, I even notice a benefit on performance! Immediately I replace tons of code removing timers with This is not about me, but about a community that all can benefit from what I'm trying to express here. TDLR: PR should be documented not documentation!For people who don't understand the importance of a good PR: View them as your wife/husband/partner, you love her/him so you will polish the relationship, take care of each other, all gestures have a meaning and when talking about each other you talk with pride and joy. (This is what your PR should represent, something you did with love, invested your time to bring something for the better, and always write it as best you can because when you present the PR you do it with pride and love [The PR description]) With media queries PR I can feel that exact love from its description, author is not just documenting the PR, is creating a tale, a tale that following PRs should continue! "Overkill" or not if you keep this rule your repo will outstand. |
Beta Was this translation helpful? Give feedback.
-
|
Dude, you just restated your original comment with more words. I understood you quite well the first time. Contributors simply aren't going to do this stuff. Even putting aside such things as language barriers and intrinsic writing skills, the target audience of each PR is the developer(s) reviewing it. It's not going to be approved or rejected by third parties who are interested enough in the project to track unreleased changes, yet simultaneously not interested in reading the code. Maybe the needs of the reviewers coincidentally meet the needs of those third parties, in which case great, but this isn't required and I don't think ever will be. My advice is either to be patient and wait for the documentation to catch up, or to be the change you want to see and help create it. Documentation is what you actually want, you clearly like to write, and documentation is best when it's written coherently by one person or a small team. Right now you could even apply to join the core team as a technical writer and get paid to do what you are asking dozens of internet strangers to do for free. |
Beta Was this translation helpful? Give feedback.
-
Not everything needs to have a motivated example. If you already know what Avalonia/src/Avalonia.Base/Data/AssignBindingAttribute.cs Lines 5 to 16 in 46d4735 Furthermore, you can search for There probably should be a public writeup for the 11.3 launch that highlights the key features in broader terms, but this is a development feed for a beta. Getting comfortable reading source code, tests, PRs, etc here is more valuable than docs although it sometimes takes more time. |
Beta Was this translation helpful? Give feedback.
-
Full Changelog: 11.2.6...11.3.0-beta1
What's Changed
Features
ItemsControl.PreparingContainerevent by @TomEdwardsEnscape in AddItemsControl.PreparingContainerevent #14153[GeneratedComInterface]based Windows automation by @maxkatz6 in[GeneratedComInterface]based Windows automation #16543Binding.Delayfeature by @TomEdwardsEnscape in AddedBinding.Delayfeature #16805classname) syntax on Style and ControlThe. by @workgroupengineering in feat: Allow use of (Classes.classname) syntax on Style and ControlThe… #16938WrapPanelitem alignment by @TomEdwardsEnscape in AddedWrapPanelitem alignment #17792Enhancements
Performance
List<IObserver<T>>.ToArray()allocations inLightweightObservableBaseby @xoofx in RemoveList<IObserver<T>>.ToArray()allocations inLightweightObservableBase#18316Fixes
VirtualizingStackPanel#17460 by @BobLd in Ensure VirtualizingStackPanel correct element size estimate and fix #17460 #17461CompilerGeneratedAttributeby @TomEdwardsEnscape in Correct which types receiveCompilerGeneratedAttribute#18166Miscellaneous
This discussion was created from the release 11.3.0-beta1.
Beta Was this translation helpful? Give feedback.
All reactions