Developers will not touch PR unless they’re tagged on it, or at least some other developers are. All of them are tagged on numerous PR’s they check on daily and review. This is how it works, you’re supposed to give review if you’re tagged or PR is relevant to your module and you need to provide module feedback.
PR with no reviewers attached is basically WIP, why would any developer look at anything without any reviewers attached and think I must provide commentary on this and merge? Development isn’t a forum where everybody says their opinions, it’s a job for these people and they only have time for PRs that are relevant to them and are requested to review.
You can find out who’s relevant developer for your PR and tag them to review. You can’t expect anything to happen without that step. I’ll give you a help and tell you to tag Campbell Barton and Harley Acheson, I think they’ll find a home for these PRs
How about focusing on only one of them at a time, instead of presenting them all at once? Maybe start with the simplest, most non-controversial and non-disruptive patch/design, and get it to a reviewable state. I think that would more likely get some time from the stakeholders.
(Well, I’m bit conflicted writing this, considering how my tiny patch could not get any attention from developers. Modelling and viewport teams are really short of hands I guess.)
All your PR have the WIP label this is used to indicate the PR is not ready for review that the Code is so work in progress
two you have not added the relevant modules, project that should review it . there is a full page on how to search for reviewers as linked above by Thomas.
Patches like this tend to get lost because there is no way to search them if you don’t know they exist. adding a label or project will make the PR appear in the workboard of the relevant module.
Author of this PR did not He just added bunch of stuff on development and expected developers to discover them and get mindblown by amazing features.
I’ve never expected any minds to be blown, or for people in a position to do anything about it to stumble upon a WIP PR or an unassigned design doc. In the past I had assigned people as a reviewer, and asked other people directly what they wanted. Nothing came of that back then, so I go into it one last time assuming the same outcome. To do otherwise would be me acting like you say, expecting people to be blown away by the minor stuff that I am doing. I couldn’t figure out a way to tag anybody or assign it to a module on the new website, so I asked what I should do. I even said “If I shouldn’t bother people, I understand.”
I’m told to ping somebody and post the design doc in the module chat. I do that, and things proceed as if I hadn’t said anything. I’m not impatient, and gave people the benefit of the doubt so I waited a few days. Nothing changes, so I move on. I wasn’t going to say anything about it, but it felt right considering what people were saying here. I don’t think too many people would have done what I’ve done, and take things as well as I did. I’ve seen enough reactionary behaviour about the slightest of percieved disregard. I don’t take anything personally, and apologize for any misunderstanding. It did get some kind of discussion going at least
If there’s any further development, I’m fine with doing whatever, but I honestly don’t see what else I have to offer.
How about focusing on only one of them at a time, instead of presenting them all at once? Maybe start with the simplest, most non-controversial and non-disruptive patch/design, and get it to a reviewable state.
I did, I went with auto xray by itself back then since it seemed the most likely to have any sort of possibility. Response from a dev was that it didn’t handle the entire issue, and was incompatible with other related requests. Make design task, see what happens. That took a while, because I don’t know what I’m doing and had a lot of other things to do, but I eventually did it.
If the patches are ready for review, best to remove the WIP markers, as WIP is taken as a marker for “This is not ready for review yet” hence few if any devs will pay any attention to such patches.
@LazyDodo it appears that @lcas followed the steps he was asked to (remove WIP label and tag the reviewers), could you verify that the patches (see links in this post X-Ray selection experiments build - #169 by lcas) are all in order and ready for review? If not, could you make the necessary amendments to make sure they will be reviewed?
Oh we gave it a shot once or twice, supporting patches that weren’t going to master - buuut they quickly broke and since we weren’t the authors, some of the patch work was hard to maintain or upgrade. So sliding in a core feature to later have it slide out - we thought it not great for the users (not be able to guarantee a feature) and too much upkeep for now (hard to maintain due to labour limits, we all volunteers).
Maybe later with more man-power we could maintain core features, but in general if we need something in core, we try commit it upstream to see if it can go into master, then have it bleed back down to the fork. Less maintenance overhead and more users can use it (ei, batch rename collections).
In general, BFA tries to focus only on GUI and UX based code with the paradigm it has, but core features: that is up to the Blender devs due to that reason. May change… but who knows.
On a side note: this build looks promising! Will try it out later this week.
But near select grabbing unseen edges and faces is pretty terrible. Unusable in my opinion. That one should be contenting for priority one, and who knows maybe it is, and it just takes a really long time to get anywhere.
Such a things are pretty common, for example, circle selection bringing random unexpected vertices selection has been spotted quite regularly, during 2.5 and 2.8 development cycles.
Modelling and viewport teams are really short of hands I guess.)
He just added bunch of stuff on development and expected developers to discover them and get mindblown by amazing features.