#Events and EventBus

1 messages · Page 4 of 1

outer steeple
#

if there's one thing you need to do in java, it's that you don't rely on the JIT to optimise your code 😛

rigid gust
#

Nah, that's a slippery slope... the jit does a pretty good job usually

outer steeple
#

an uncanny amount of class gen would get it down to 1 cast thinkies

#

well technically 2

rigid gust
#

maty we're gonna need a decision on what to do with this PR

outer steeple
#

i'm going to need you to stop using definitive pronouns

outer steeple
rigid gust
outer steeple
#

honestly if squiddev's stuff brings a 40% boost roll with that

#

ASM code gen doesn't need maintenance and that code is mostly clean and easy to understand

#

it's not like by using LMF we aren't simply moving the code gen somewhere else to a worse impl

#

the asm transformations were always the biggest problem to me, generation is fine by me

primal mist
#

i wish java methodrefs worked like C#

#

no runtime codegen, just an object that contains an object and a method handle [and a linked list for some reason] that the runtime knows how to call

rigid gust
agile slate
#

didn't I bring up at some point that the asm stuff causes issues with class reloading in dev

rigid gust
#

Does it?

#

With the jbr?

#

Does it handle lambda objects correctly?

agile slate
#

but not everyone has the jbr

rigid gust
#

How could the asm stuff cause issues then? If the method signatures don't change it shouldn't matter

agile slate
#

I haven't encountered it in a long time since I use jbr now but as far as i can remember it was some asm for either @vernal latch or @Mod.EventBusSubscriber

mellow hearth
#

It was SubscribeEvent, if your method wasn’t public it would transform it for access iirc

#

There was also the fact that any custom Events would also kill your hotswap unless you implemented what the event transformer did yourself

#

Single Class Hotswap is nice for allowing you to work around that

outer steeple
#

neither of those are related to the listener class gen tho

#

so it's fine

mellow hearth
#

Yep, listeners afaik where fine

rigid gust
#

Yeah that looks fine either way

pallid kraken
#

I'm not sure if this is related, but why is EventBusSubscriber inside of Mod? Also, is it possible to use SubscribeEvent without EventBusSubscriber and if not, why is one in EventBus and the other in FML Java?

latent rivet
#

@SubscribeEvent is also used when you register a class or an instance thereof via IEventBus#register()

lone kelp
#

looks at !events

pallid kraken
#

Hm yes I forgot about that functionality

latent rivet
#

The reason EBS is in fmljava is that the auto subscriber that uses it is part of fmljava. Could it be extracted to a higher level? Maybe

pallid kraken
#

I just think that EventBusSubscriber should be in the same package as Mod, but not an inner class of Mod. EventBusSubscriber has its own inner class too (Bus) so there are three levels of classes.

#

It would be nice if EBS could be part of EventBus though

latent rivet
#

The annotation could be, the functionality can't because it relies on FML's annotation collector

pallid kraken
#

Ok, that's fine then. I see it has Minecraft-specific fields too.

#

I would still like to know why EBS is an inner class of Mod and not in its own file

rigid gust
#

Had a bit of time to test Squid's snippet

#

It works great with a small tweak (one if the ALOAD 0 should be inside an if check)

#

Testing shows about 120 ns for 100 listeners in the besg case, which is IMO good enough (I get 80 for LMF, but I prefer not reflecting into JDK internals)

#

I'll try changing IEventListener to an abstract class tomorrow

#

@agile slate can we get a 20.2 FML branch so I can make the event changes there?

#

I can have everything written for tomorrow

agile slate
#

oh right I have permissions on that repo now... will do (after minecraft live)

haughty current
outer steeple
agile slate
rigid gust
#

Missing a webhook?

agile slate
#

maybe but I did it through the UI so no push

rigid gust
#

Ah I see

#

Let's see what the #project-talk discussion gives heh

rigid gust
#

looks great, thanks for the PR

haughty current
rigid gust
#

I like it like this

#

somehow typetools doesn't work anymore after your PR

#

no clue why

haughty current
#

Oh, that's very odd. Do we pull in a more recent version via modlauncher/sjh?

rigid gust
#

ah that's a good point, let me check

#

doesn't seem to be the case

haughty current
#

Hrrm, odd. Happy to take a look if you want to focus on other stuff. Was sure I ran tests, but clearly not on the final branch :/.

rigid gust
#

fuuuck I know what's up

#

I hate typetools

#

typetools lambda resolution is disabled because it can't find sun.misc.Unsafe at some point during its startup

haughty current
#

Wait, why does that need unsafe?

rigid gust
#

look at this 🤮

#

(TypeResolver.java)

#

that's weird, if I add back the dependencies in the test build.gradle it works again

#

implementation('cpw.mods:bootstraplauncher:1.1.0') makes a difference

#

SJH is enough

#

could it be that sun.misc.unsafe is not on the classpath by default?

haughty current
#

Ahh, yep - adding a requires jdk.unsupported; to module-info.java fixes it.

rigid gust
#

indeed

#

why is this even necessary... it should be an automatic module

#

oh no yeah of course... automatic modules won't read jdk.unsupported unless another module requires it

haughty current
#

Oh, is IEventBusInvokeDispatcher not actually used anywhere? Nice!

rigid gust
#

yeah and I fear that if someone ever passes a custom instance to the bus it will force-deoptimize post and destroy performance

haughty current
#

Yeah. I was assuming it was used somewhere in Forge, but if not that's awesome.

rigid gust
#

it isn't heh

#

(might have been used before mod busses were a thing)

haughty current
#

Yeah, I got slightly side tracked yesterday at putting all the event listeners in a single method handle. It's not viable for many reasons (IEventBusInvokeDispatcher being only one of them), but it is fast :).

rigid gust
#

How so? Spinning a class that does the entire dispatch?

#

Hidden classes are GC'ed so technically this would be possible ^^

haughty current
#

So the custom exception handler is a bit of a pain (it requires the index of the erroring handler, though I feel it's not the end of the world if it's removed - it's mostly reconstructable from the stack trace), but my main concern is the dynamic registring/de-registering of event handlers.

#

MethodHandles are pretty good at only generating classes when needed, but I've also seen some pretty nasty mods which register (and unregister) event listeners for each block entity, and I'm sure they'd hold up in the face of that :).

rigid gust
#

Ah, yes of course

#

We'd also have to be careful not to exceed method bytecode limits

rigid gust
#

@outer steeple do you have some time for eventbus tonight? Can I get some green?

#

Or just let me finish it stabolb

outer steeple
rigid gust
outer steeple
#

@rigid gust question: with the removal of IEventBusInvokeDispatcher how do you plan on making mod bus posts use the priority

rigid gust
#

I want to add post(Event, EventPriority) to only post for a specific priority

#

note that IEventBusInvokeDispatcher is not used atm, the entire eventbus invocation is wrapped

outer steeple
#

well then, can't see anything obviously bad in that pr

rigid gust
#

alright, thanks!

rigid gust
#

then there's the question of abstract events that needs resolving and we'll be good to go

wheat sinew
#

penultimate PR 👀

rigid gust
#

(there will be more things to adjust I suspect but at least this will make the refactor complete™️)

wheat sinew
#

I screm at the fact that the "an exception will be thrown" exists in the prose body and not as a @throws

rigid gust
#

copy/pasted from the other post 😛

wheat sinew
#

which you wrote stabolb

rigid gust
#

oh... oh yeah I did harold

wheat sinew
rigid gust
#

back to abstract events

wheat sinew
#

now I'm tempted to make a PR to fix that kek

#

but I must resist

rigid gust
#

should something like the following be allowed?

public abstract class Event {...}

public class ParentEvent extends Event {}

public abstract class SubEvent extends ParentEvent {}

public class ActualEvent extends SubEvent {}
#

this means that you could listen to ParentEvent or ActualEvent but not to Event or SubEvent

wheat sinew
#

what would be the reason not to allow it?

rigid gust
#

you could register a listener to ParentEvent and filter for SubEvent instances, that would be equivalent to registering a listener to SubEvent

#

I don't think people would do it by mistake, it's just a bit odd

wheat sinew
#

so would the question more be -- do we require all superclasses of an abstract event to also be abstract...?

#

or wait, no, that wouldn't be checkable until SubEvent is dispatched

rigid gust
#

indeed

wheat sinew
#

how would we prevent such a situation, even?

#

setting aside the question of should we -- could we?

rigid gust
#

well it would be checked when dispatching one of the subevents

wheat sinew
#

on its face, sounds like a performance penalty -- crawling event inheritance on dispatch

rigid gust
#

oh don't worry about that - this is only checked once when creating the listener list

#

all of this has no performance impact on dispatch

wheat sinew
#

i... don't follow

#

if we can only check during the dispatch of the event (as you've said above), that means the check must happen during or after that disptach, no?
so such a check would have to happen at least once

rigid gust
#

the first time either a dispatch or a registration occurs, a ListenerList is created

wheat sinew
#

hmmm

rigid gust
#

what I am saying is that this does not impact firing the event again

wheat sinew
#

hmmm

#

i can't think of a situation at present in which we would have an event strucutre laid out above

#

so I'd lean towards disallowing it

#

if ever we're wrong, we can allow it again and it shouldn't pose any compatibility issue with preexisting code

rigid gust
wheat sinew
#

just a stray thought to put out there: once you've finished with your so-far-planned changes, Tech, we'd probably want to consider closing this thread down and moving discussion to another channel

rigid gust
#

yeah sure

rigid gust
#

thanks sci

wheat sinew
#

huh, does Bus have no license headers?

rigid gust
#

not on the new files, no

#

we need to figure out licensing for every project because the copyright is shared between neoforged and mcf

wheat sinew
#

prelim thoughts:
leave license headers on existing files (that are for MCF)
add new license header solely with "NeoForged and contributors"
make it policy so if a class is heavily rewritten since the fork such that it's not substantially similar, the license header should be updated

#

@rigid gust what's the unwrapping done for?

#

...I might be starting to understand, right after I pinged you kek

#

okay yeah, I think I get enough of the why

rigid gust
granite nimbus
#

Yeah, I believe their licenser plugin can do it

rigid gust
pale grove
# 
    // Skip legacy Forge Development LLC headers
    skipExistingHeaders = true
#

the Cadix licenser can do this with the flag set

#

New headers become NeoForged and contributors

#

Existing files stay MCF

#

And manual review ("make it a policy") will change the header if a class is heavily rewritten

#

Let's try not to get too deep into NIH when we have perfectly good tools that do what we need :p

rigid gust
#

Ah cool

outer steeple
#

now do a cleanup

rigid gust
#

fuck 😄

outer steeple
#

do a pass on all docs to make sure they don't reference bad stuff or have incorrect docs, format all classes to same-line brackets, and rename constants (like this one)

#

and that's an order stabolb

rigid gust
#

Technically that constant is in order

#

static final fields should only be capitalized if they are constants

#

but yes I'll do it after this last PR is merged

outer steeple
#

no

#

i'll stabolb the technicalities out of you

#

smh

#

eh

rigid gust
#

yes but it's good enough™️

#

this is only used for mod bus events after all

outer steeple
#

i'd say it's probably worth keeping another built view of per-phase

rigid gust
#

we can do it

outer steeple
#

maybe as a bus parameter

rigid gust
#

ah yes, smart

#

something like BusBuilder#allowPerPhasePost?

outer steeple
#

yeah

rigid gust
# 
Benchmark                                          Mode  Cnt     Score     Error  Units
ManyBussesBenchmark.testManyBusses                 avgt   15  1314.180 ▒  81.052  ns/op
ManyBussesBenchmark.testManyBussesPerPhase         avgt   15  6869.793 ▒ 447.127  ns/op

better

#

I updated the PR

haughty current
# 
- return listenerLists.computeIfAbsent(eventType, ListenerList::new);
+ return listenerLists.computeIfAbsent(eventType, e -> new ListenerList(e, allowPerPhasePost));

This change now means we need to allocate a lambda each call. I'm not sure if that actually matters in practice though, possible the call to computeIfAbsent gets inlined.

rigid gust
#

the lambda is only allocated when the first get call returned null (i.e. at most once per event type)

#

and the second lambda already captures this to call getListenerList

haughty current
#

and the second lambda already captures this to call getListenerList
Ahh, so it does. Gah.

rigid gust
#

usually the value gets computed

#

the value can only be already in the map in computeIfAbsent in multithreaded contexts

rigid gust
#

@outer steeple do you have time for eventbus review? so I can update FML 😛

#

thanks

latent rivet
#

shouldn't we remove the "this event is/is not cancellable
@rigid gust IMO no, nothing requires that every "leaf" of an event inheritance "tree" implements ICancellableEvent, it could also be a parent class that may not be in the same file

rigid gust
#

hmmm yeah

deft palm
#

i think I would much rather have each "leaf" add implements ICancellableEvent to the type again instead of adding it to the documentation of each event. The information density is just higher imo, this info can be documented by the type, so there should not be a need for it to also have it in one line in a 5 to 10 line javadoc.

granite nimbus
#

It should be in the documentation, because the documentation should explain what cancelling it does

#

Don't tell us what in the docs, tell us how/why

rigid gust
#

The point is that events that are NOT cancellable also have this javadoc

rigid gust
granite nimbus
#

"this event isn't cancellable" isn't very useful - like, no shit it isn't cancellable. Cool. I don't even know what cancellable would mean in this context

#

Unless there's a notable reason it isn't cancellable, that is

rigid gust
#

Yeah IMO javadoc for cancellable events only

#

However I won't be changing this now, we'll see later with the rest of the team

deft palm
# rigid gust A bit cursed:P

less cursed than three lines of javadoc for "does not have a result" "is not cancellable" and "fired on the mod event bus". The first is removed, but the other two are the presence of interfaces and java already has a really nice way of showing the existance of interfaces. And yeah, some events have not directly obvious results when cancelling events, but minimum 50% of the events are obvious by the name of the event or the documentation of the Event without that part. But not having to write "this event is not cancellable" on each not cancellable event is already a plus

granite nimbus
#

If an event is cancellable the docs should say why and explicitly say what that means. If it isn't the docs need not mention it

rigid gust
#

damn, getting sniped by my own changes 😄

image.png
rigid gust
#

I'll have to go back to silently ignoring the event

outer steeple
#

screm wat

#

start the bus earlier

rigid gust
#

we really shouldn't

humble junco
#

why does the bus start so late?

rigid gust
#

it only starts after mod loading is fully complete

#

(atm)

#

so we have two options here:

  1. start forge bus earlier
  2. go back to ignoring these events
#

I think 2) is better... I'm happy to consider 1) at a later time but not for the 20.2 initial release

rigid gust
#

ok with this change I can get into a world in forgedev again using all the updated deps

#

gonna merge in a few minutes if nobody objects

wheat sinew
#

that would mean silent failure if something tries to fire an event on a shutdown bus

#

which doesn't sound ideal

rigid gust
wheat sinew
#

how did that not trigger in the past?

rigid gust
#

IMO throwing an exception is too dangerous because events are posted in many places and there's always a chance that some forge bus event could be fired "too early"

rigid gust
wheat sinew
#

... screm

#

very well then

#

though it should probably be noted on the post methods' docs that posting on a shutdown bus does nothing

#

there's also the idea of having some form of optional logging for events posted on shutdown bus, like controlled via a system property or logged via a (deny-by-default) logging marker

rigid gust
#

if we do this we're gonna spam the user with forge-posted events

rigid gust
wheat sinew
#

first, that's why I said optional -- explicitly to be enabled only when requested, like during some sort of debugging session
second, that's only going to happen to events posted before the bus starts up, which I would assume to be a minority of all events posted to the bus

wheat sinew
rigid gust
#

I don't want users to start the forge bus 😛

#

idk if they would but maybe we shouldn't link the method?

wheat sinew
#

there's no way to query whether a bus is started yet, right?
if there was, I would suggest that getter

#

i like linking the method because it links the reader to what "started" means, in the context of the event bus

#

but eh, probably fine to omit the link in this case

rigid gust
#

we could add it but heh I'm not a fan of the system... ideally that should not be a public method on the bus

#

amended the javadoc

haughty current
#

Probably a discussion for a later time, but if bus now requires Java 17, it might be nice to make EventListener a sealed class.

rigid gust
#

it's in a module so it should work fine with generated listeners

rigid gust
#

actually, we can't make it sealed unless we introduced a base class for the generated listeners

haughty current
rigid gust
haughty current
#

Haha, beat me to it :p

rigid gust
#

oh lol sorry 😄

haughty current
#

Hrm, GeneratedEventListener should maybe have a package-private constructor. Really net.neoforged.bus; shouldn't be exported at all - I think the only thing used from it is the EventBusErrorMessage, though obviously haven't checked the latest versions of NeoForge :p.

#

Maybe that stuff should wait until the other breaking changes though. Definitely not a priority :D

rigid gust
#

if a mod tries to use a nonexported package it will just crash at runtime

#

I don't think IDEs support a module path for a non-modular project (the gradle java plugin doesn't)

haughty current
#

I guess one could move things to an internal package, and chuck an @ApiStatus.Internal on it, but probably not worth it. Ahh, one of these days JPMS will actually be friendly to use, and I can be at peace.

rigid gust
#

All of non-api is internal

rigid gust
haughty current
rigid gust
#

yeah I know... :/

honest timber
#

i have dumb question about the codebase, why does one there is IEventBus EventBus but then BusBuilder and BusBuilderImpl?

rigid gust
#

Use the ones in the api package only

honest timber
#

im just asking why this choice of naming for specific classes

#

not which to use

pallid kraken
#

They mean that both IEventBus and BusBuilder are interfaces but one uses the I-/no affix convention while the other uses the no affix/-Impl convention

#

The consistency of interface naming has been brought into question but I think the plan is to hold a community vote first and then perform all renames at once

rigid gust
#

Ah, right

#

Maintainer vote at a later time probably

pallid kraken
#

Why would only maintainers be able to vote?

agile slate
#

because that is a design decision for the project

inland imp
#

NeoForge does not allow the general public to vote on design decisions

pale grove
#

I hope you can see the obvious problem with letting everyone vote on things like this

indigo cloak
#

they'd just vote to name the interface BussyMcBusFace

mellow hearth
#

damn there goes my name idea

pallid kraken
#

I heard that the last time such a vote happened it was a community vote. Why would that be a bad idea?

rigid gust
#

random people voting don't necessarily know enough to give an informed opinion

#

having that said we have a non-binding community vote

pallid kraken
inland imp
#

People can make their voice heart

#

But we are under no obligation to listen to them

#

Even if they are the 99% majority

granite nimbus
#

A poll is just a large-scale way of collecting that information

#

And if most mod devs do want that removed, that is something to consider and it substantially hurts a project to reject that sort of feedback - of course, we don't know what opinions most devs have on this because there hasn't been a poll

inland imp
#

It would be weird if we did not

#

But there is no rule, or convention that forces us to listen

pallid kraken
#

Yes, I understand there is no obligation

inland imp
#

Sadly some within the community don't seem to understand that

#

So for right now

#

We are reserving the voting option within the community for those moments where the maintainers can not come to a reasonable idea first, or for those moments where we feel like community input is very valuable

granite nimbus
#

I'm sorry, "some people in the community think the results of a poll are the be-all, end-all of decisions, and thus we're not going to bother reaching out to the community for feedback at all except when we're stumped"? In what world does that follow?

inland imp
#

With respect to the format, we feel like that putting the vote to the communtiy would result in a deadlock

#

And as such we have decided for now that we are not putting that vote out

outer steeple
#

i would like to point out that given our "pollution" of the maintainer team, a maintainer vote isn't that much different imo

#

also i'm not sure how and when that was decided but w/e

inland imp
granite nimbus
#

If decisions are made - like this - by "the neoforged team" to do or not do something, that decision and the process to reach it should be put somewhere public - because otherwise it's very hard to tell the difference between "we, neoforged, have decided" and "I, orion, have decided"

granite nimbus
inland imp
#

Yes, but that does not indicate that we are not putting out a vote on the formatting topic, because there are people who do not understand the format of the poll......

granite nimbus
#

We are reserving the voting option within the community for those moments where the maintainers can not come to a reasonable idea first, or for those moments where we feel like community input is very valuable
...

inland imp
#

We simply feel like the topic right now is not ready for it, and we can not learn from a poll, more then what we already know: it is more or less half split on the interface with or without I issue. Given that this has already been researched in the past.

granite nimbus
#

Which is literally exactly what I pointed out as flawed...

gusty dove
#

are we arguing over the name of a class

granite nimbus
inland imp
#

Somewhere in this discord

granite nimbus
#

A reaction poll somewhere? That's hardly large scale enough to tell you jack

inland imp
#

I know because we added spotless to NeoForge and this came up

indigo cloak
#

there was an I-vs-no-I poll a long time ago (either for 1.13/14 or the MCP->Moj migration)

inland imp
granite nimbus
inland imp
#

In different locations

#

Hell I am pretty sure it was discussed in the last month

#

Somebody even dug up the old oracle standards

granite nimbus
#

It has been discussed to no end

indigo cloak
#

IList thinkies

gusty dove
#

personally I have the hot take that naming is not worth arguing over when there are other things to get done

inland imp
granite nimbus
#

I've not seen a recent poll in a large, public space about this

inland imp
#

And made the decision

#

We made the spotless configuration public

#

Under the pretense that we will revisit it in the future again

#

When we have collected feedback on the current applied style

#

This literally happened monday

granite nimbus
#

So... what are the plans to collect feedback?

#

Where's the big "style feedback" discussion?

#

Where's the poll?

indigo cloak
#

do we need a discussion thread on everything

granite nimbus
inland imp
#

Use it, provide feedback, here: 1131782966989828156

#

Shit thread ids don't work

#

There is a thread in #1105595318197825557

granite nimbus
#

That one?

inland imp
#

Discuss it in #squirrels-🦊 or #general or that thread

granite nimbus
#

That sort of feedback is fundamentally flawed, as we saw from the versioning fiasco - it's really just "who's talking the most". A poll, on the other hand...

mellow hearth
indigo cloak
#

yeah like I really don't care if half the interfaces start with I and half don't

gusty dove
#

same

granite nimbus
indigo cloak
#

I flip a coin whenever I PR new interfaces

granite nimbus
#

I care for "make it consistent" far more than I care for "use I" or "don't"

mellow hearth
granite nimbus
#

Might want to read the backlog a bit

inland imp
#

he is making an issue of me telling that we are not putting it to a vote...... an informative community vote.....

granite nimbus
#

A poll is different from a vote

#

I'm taking issue with Orion's approach to community feedback and his failure to clarify what is his view and what is the view of the whole neoforged team

inland imp
#

As far as I am aware: I have not stated anything that is not the opinion at the moment of the NeoForge maintainers

mellow hearth
inland imp
#

I might be wrong

#

But I am human

#

If so, any other maintainer is free to point this out to me

#

As per our own guidelines

gritty lily
#

luke are you seriously trying to flip the table and demand a community vote on the letter I????????

granite nimbus
#

Wut no?

gusty dove
gritty lily
#

so what's going on here. i'm not able to catch up everything and that seemed to be your beef

granite nimbus
granite nimbus
#

I am saying that information about what the community thinks should not be collected through random threads

gritty lily
#

wow, that's 100% pure context free gibberish

granite nimbus
#

Because that's just "who talks the loudest"

#

But by a poll

gritty lily
#

is it a serious impactful topic?

indigo cloak
#

it is not

inland imp
#

No

gritty lily
#

where there is some serious differences of opinion and it needs a widespread community input?

inland imp
#

Which is literally what I said, as to why there is no vote.....

#

Or poll....

#

Or community input

granite nimbus
#

If information is not collected by a poll, that is fine - however, don't go arond claiming you have collected community feedback then!!! That's the thing I'm taking issue with...

viscid mangoBOT
#
oriononline

[Reference to](#1136448404495532133 message) #1136448404495532133 [➤ ](#1136448404495532133 message)We are reserving the voting option within the community for those moments where the maintainers can not come to a reasonable idea first, or for those moments where we feel like community input is very valuable

indigo cloak
#

community feedback was collected from prior polls on the subject, I'm pretty sure it's always been 50/50 split

inland imp
#

There was a whole thread on this

gritty lily
#

what is the topic?

granite nimbus
#

Where's the poll?

inland imp
#

Formatting, specifically I or no I

gritty lily
#

really so i was right?????

inland imp
granite nimbus
#

Public polls aren't "random message burried in a thread somewhere"

gritty lily
#

FFS

#

dude: this has been litigated to DEATH for almost 10 YEARS now

lone kelp
granite nimbus
gritty lily
#

you will never reach a community accord because it's the definition of trivial "colour of the bikeshed" stuff

inland imp
inland imp
granite nimbus
#

...those threads are for, uh, brainstorming, right?

#

Might want to rename the channel if not...

gritty lily
#

these threads are exactly where community feedback happens luke.

indigo cloak
#

brainstorming is a kind of feedback

granite nimbus
#

Not... really...

#

It's feedback from a very limited subset of the community

gritty lily
#

brainstorming is literally where the community brainstorms on ideas around a topic to see if there's merit

swift stream
#

Where exactly are we supposed to go to get the kind of community feedback you want then?

gritty lily
#

god i think

#

a vote on github is probably what they're looking for

granite nimbus
gritty lily
#

but that's pointless

#

for this specific topic

#

because it's literally been done to death a billion times

inland imp
#

Any given topic can have different ways of collecting feedback......... Sometimes it is a github discussion, sometimes a twitter poll, sometimes a discord thread, sometimes a discussion in #squirrels-🦊

gritty lily
#

if luke has somehow managed to sleep through every other debate in the entire world on the matter for the past 20+ years ,that's their problem, not ours

granite nimbus
gritty lily
#

exactly orion. there's plenty of reasons to do all those things. but not for this particular topic

indigo cloak
gritty lily
gusty dove
#

i see no reason to invest more than approximately 30 seconds in the formatter

indigo cloak
#

some things aren't important

gusty dove
#

pick a standard, create all new code following that standard

#

done

gritty lily
#

yup exactly embeddedt

inland imp
gritty lily
#

great. what's the rule @orion?

granite nimbus
#

Sure, but like... that would take a maintainer vote, right? How much more complicated is it to set up a community vote than a maintainer vote?

gritty lily
#

is it I or no I?

#

just so i know for next time

viscid mangoBOT
#
technici4n

[Reference to](#1136448404495532133 message) #1136448404495532133 [➤ ](#1136448404495532133 message)Maintainer vote at a later time probably

lukebemish referenced ·
granite nimbus
#

Apparently the lack of decision there is the whole issue

gusty dove
#

we are not even out of the BC window yet

#

stuff can be renamed later

gritty lily
#

yup

#

this is literally the definition of trivia

#

it's even worse than the version number thing. because at least that has some actual meaning

inland imp
granite nimbus
#

cpw you seem to misunderstand what I'm taking issue with...

gritty lily
#

wondering what tech decided. i really don't care either way.

granite nimbus
#

I'm not saying "we need a community vote right now"

gritty lily
#

aren't you?

granite nimbus
#

...no? Wut?

gritty lily
#

that seems like acall to a community vote RN

granite nimbus
#

I'm saying that a community vote for this would be more informative than a maintainer vote...?

inland imp
granite nimbus
#

I'm not syaing either of those should happen right not

indigo cloak
gritty lily
granite nimbus
#

I'm saying when it does happen you should survey the community

inland imp
#

Yet when I am telling you that it won't happen now, you seem to take offense to that

granite nimbus
gusty dove
#

honestly formatting is one of the things I really wouldn't care if they skipped surveying the community on

inland imp
gusty dove
#

it has zero impact on the runtime functionality of the code or the feature set

outer steeple
#

it's not a standard within neo itself but that's another matter

granite nimbus
#

That's what started this...

inland imp
#

Those are three different messages

granite nimbus
#

yes

gritty lily
#

do extremely sarcastic polls count luke?

queen stratus
#

#1136448404495532133 message Was discussed here iirc and it was, at the time, said it's not important so stick with the I prefix

viscid mangoBOT
#
technici4n

[Reference to](#1136448404495532133 message) #1136448404495532133 [➤ ](#1136448404495532133 message)went for ICancellableEvent

danorris referenced ·
inland imp
#

The first one was targetted at a comment made earlier

#

The other two at a different statement

granite nimbus
gritty lily
gusty dove
#

uh

#

is twitter even a representative sample of minecraft modders

outer steeple
indigo cloak
#

I can't vote in twitter polls

#

guess it'll remain forever undecided

#

gonna keep flipping my PR coin

gritty lily
#

that's the point. NOTHING reaches the perfect audience. Community votes are just going to be my twitter post, with more buttery language.

granite nimbus
gritty lily
#

and usually not a very useful one

#

there can be times, as orion said, that we need to solicit wider feedback about something where we honestly can't decide.

#

but those are likely the exception, because they're going to have to have a lot of wider context. which most people will explicitly ignore.

granite nimbus
#

Why shouldn't you solicit wider feedback in other situations as well? Especially for something as unimportant, but highly visible, as this, where it doesn't exactly require domain-specific knowledge?

gritty lily
#

a "community vote" isn't going to tell you much except who can vote on the GH discussion or twitter poll or whatever.

granite nimbus
gritty lily
#

the wider context for I vs not I? there isn't any. i fully expect this vote to go down to 50/50. because that's what's happened every other time

#

my point here on this specific issue, is that it's meaningless.

#

a "data point". an unhelpful "data point" at that

granite nimbus
gritty lily
#

but for real stuff, that actually matters, there will be context and it'll mostly be ignored.

swift stream
#

and that's even assuming polls aren't botted or otherwise manipulated

#

which they will be

gritty lily
#

heh wrong reply LOL

granite nimbus
gusty dove
#

if everything is put to a community vote nothing will get done

gritty lily
#

and yes, we've inherited a codebase that has been confused ont he matter. shit happens. there's 10+ year old code here and not everyone has always been "strict" about such trivia

granite nimbus
#

I'm not saying that everything needs to be put to a community vote either...

gritty lily
indigo cloak
#

in this case

  1. the maintainers came to a reasonable idea first
  2. community input is not very valuable for this specific subject
pale grove
#

How about a compromise then.

gritty lily
#

Yeah, we're going to use LOWERCASE i

granite nimbus
# gritty lily except you seem to have beef with us saying that?

I'm saying that when there's been an expressed interest in making something a community vote, and when it's a pretty simple yes/no thing, and when setting up a poll is thus fairly easy, and when it doesn't need domain specific knowledge, surveying the community is probably smart

gusty dove
#

Apple will probably be very happy as well 😉

indigo cloak
gritty lily
pale grove
#

Things that can reasonably be put to the community without causing endless bikes he'd, will be.
Things that are a matter of trivia and don't actually affect anything (such as naming conventions), will just be dealt with by the team we created for that exact purpose.

gritty lily
#

ALL BIKESHED all the time

pale grove
#

That's worded very carefully on purpose because of a couple important points

#

First: the community and "the modders" are a very different group entirely. The vast majority of "the community" don't know what an interface is, and are incapable of voting in an informed way, and are unable to consider the consequences of the decision for other people

#

Second: there are communities dedicated to botting our polls.

gritty lily
#

we have the best audience. hi audience!

pale grove
#

Third: the maintainers team itself consists of only modders. While there are thousands more modders not in our team, there are orders of magnitude more non-modders ("wrong demographic")

#

Any poll we run wouldn't be reliable at all, because you run into almost every bias there is

#

The results are not representative, they're almost certainly not the demographic you're trying to poll, and there's a very good chance that they simply don't understand what you're asking

#

(which leads to them picking what others have told them to pick, which is another bias)

gusty dove
#

from a pure statistics perspective, the results are probably not representative either way, but we cannot do anything about that

pale grove
#

This is like, the worst way to run a project like this.

gritty lily
#

exactly embeddedt

inland imp
#

I would be fine with that, since that falls under the "where the community input is very valuable section"

gusty dove
#

aside from expanding the maintainers team to include more perspectives (which is already being done)

pale grove
#

Exactly.

gritty lily
#

yeah. we're increasing the size of the teams, with people who have demonstrated their knowledge in this domain area

#

the exact sort of people who we want to trust to make good decisions for the future

inland imp
#

However I would like to note that pure polls should omly be used were appropriate

indigo cloak
gritty lily
#

or do you think that you can't trust the maintainers @granite nimbus

indigo cloak
#

"What if there was a language where every word was just the letter I a different number of times"

gritty lily
#

brainfuck

pale grove
#

That's the whitespace esolang

gritty lily
#

it's just .........[]<<>]]]

pale grove
#

It's a textual Turing machine. Don't diss my brainfuck

haughty current
pale grove
#

hehe yeah

lone kelp
pale grove
#

spabs

haughty current
#

You could do the binary lambda calculus instead I guess, that only requires two symbols.

royal veldt
#

I mean, Turing machines can encode any other Turing machine through just a sequence of 0s

gritty lily
#

mark vs space?

royal veldt
#

And using 1s as separations

#

So like

#

Technically that? Since words of only I still implies spaces to separate words

granite nimbus
#

I am rather dissapointed in how my views here have been represented. I am not calling for the community to decide stuff like this - The purpose of a poll is to collect information, not make decisions. I would point to the "which IDE do you use" poll as precedent for this. Non-modders are unlikely to interact heavily on GH discussions compared to modders. Yes, it can be botted - good thing you're not making final decisions off the result, right?

Frankly, this whole thing is leaving a bad taste in my mouth. My point has been, almost exclusively, that polls should be used to collect community feedback in cases where knowing what developers think is useful - and for naming conventions, that is useful, because at the end of the day we're the ones that have to work with your classes. Beyond that, I have been specifically arguing against the idea that polls should only be used when the maintainer are themselves in disagreement or stumped - poll should happen before any such maintainer decisions are being made, to collect information to better inform a vote there!

Folks in development spaces here like to make a habit of misrepresenting what I'm saying. So, cpw, no, I don't trust the maintainers - partially because I disagree with fundamental design decisions and decisions on what to prioritize that they have made, and partially because attempts to point this out have been met with quite a bit of bad faith. Disagree with me if you will - criticize me if you well - but for god's sake, stop misrepresenting what I'm saying

gritty lily
#

perhaps be clearer in what you're trying to say then?

#

because it reads to me like you are upset that we're not driving every aspect of this project with community votes and feedback

pale grove
#

That's the impression I've had too ^

gusty dove
#

Third

gritty lily
#

which is not a good way to run a project. and if you're not saying that, that's GREAT.

#

but then i'm unclear what you are trying to say?

granite nimbus
#

Might want to start at the top: #1136448404495532133 message

gritty lily
#

that's a 10,000 message readback.

#

which isn't super helpful as a response.

#

i'm curious what "fundamental design decisions" you disagree with however.

granite nimbus
# gritty lily that's a 10,000 message readback.

"collecting feedback when it's trivial to do so and when there has been an expressed interest in the collection of such feedback" != "driving every aspect of the project with community votes and feedback". Like, come on, hyperbole is ingenuine...

pale grove
#

Running a poll is almost always trivial. All that remains is for someone to say "let's make a poll" at every single decision point and we're no longer a sustainable project

#

It's not hyperbole, it's the implications of what you're asking from us

gritty lily
#

"collecting feedback when it's trivial to do so and when there has been an expressed interest in the collection of such feedback" is NOT trivial. not to make it an actually useful contribution to the debate.

pale grove
#

Actions have consequences, and a policy like this is extremely easy to abuse

gritty lily
#

compare my twitter vote

#

and also what curle say. if we have to stop every single time we need to make any decision to hold a day long (or longer?) vote with the community?

granite nimbus
#

And how urgent you need a decision made...

indigo cloak
#

okay, great, interface prefixing is neither urgent nor noticeable

gritty lily
#

if you arguing for impact size

#

then I is probably HUGE 😛

swift stream
#

Even impact size is subjective

granite nimbus
gritty lily
#

but it's also extremely trivial

pale grove
#

Highly noticeable? The users don't know whether there's an I or not in interfaces.

royal veldt
#

Wasn't there a poll about this eons ago in the MCP project?

granite nimbus
#

Devs do though

gritty lily
#

i'm curious luke. is I REALLY the reason you're upset?

#

silk there's been polls since before forge even existed

granite nimbus
gritty lily
#

then what is?

indigo cloak
#

luke I have very poor object permanance and can't remember anything that was said in the conversation more than like a minute ago

swift stream
#

There's thousands of messages luke, it isn't feasible to go through all of them in a discord this large, sadly

granite nimbus
#

I'm annoyed by Orion's characterization, which is apparently the NeoForged characterization, of what does or does not need community feedback

gritty lily
#

what?

granite nimbus
gritty lily
#

orion speaks for orion

granite nimbus
inland imp
#

In most cases yes, but I used a royal we here

#

He has a point

#

I used a royal we here

gritty lily
#

i have not seen any official statement on this. what curle says is probably closer to "official" position. but we haven't made any definitive statement on the project position YET

granite nimbus
#

No, Orion, you specifically said that it was the view of the neoforged project...

#

That is what I got upset about

indigo cloak
#

luke have you tried not taking what people say literally

gritty lily
#

but orion and curle agree on the fundamentals luke, so?

#

and i agree with them too

granite nimbus
gritty lily
#

community votes will be one of various tools to solicit feedback, used as and when we need to seek such feedback.

inland imp
#

I can not find were i stated that I said it was the view

#

Yes I used a royal we

gritty lily
#

it's ok. orion

inland imp
#

And yes I did that because I know the opinion of the others and the maintainers

gritty lily
#

exactly

granite nimbus
#

Link! #1136448404495532133 message

#

There you go!

gritty lily
#

OMG. he's right!

inland imp
#

Yes, the opinion of the maintainers.....

gritty lily
#

that's not quite the gotcha you think it is luke

inland imp
#

I am not sure how that could have been mistaken for anyting other that what was written there

#

Because I was very carefull when I wrote my stufff

#

I knew the opinions of the maintainers

#

And i was even sure that I knew the opinions of other SC members on this topic

#

Because it is something we have interally discussed to death

granite nimbus
#

Really? There's been a maintainer vote on this then?

inland imp
#

So I was able to make my statement, in this particular case, a royal we

indigo cloak
#

why would there need to be a vote when you're informed enough to assume things

granite nimbus
gritty lily
#

on what? community feedback for issue input?

#

or I

granite nimbus
#

I only pointed that out because a maintainer specifically stated they weren't sure when the decisions was made...

inland imp
#

And we corrected the record here

#

Several people did

#

I don't understand what I did wrong

gritty lily
#

nothing orion

granite nimbus
#

Then, ah, correct me if I'm wrong, but... if there's not been a maintainer vote, how could a decision have been made on that?

gritty lily
#

luke, do you understand the concept of consensus?

#

and agreement

pale grove
#

And functioning team :p

wheat sinew
#

votes are not the only way to achieve consensus on a matter

granite nimbus
#

Cool, that's good to know that that's what orion meant...

indigo cloak
#

sometimes a consensus just means someone went "speak now or forever hold your peace" and peace was held

honest timber
#

does anyone who pull requests to neoforge and the pull requests gets accepted becomes mainteiner?

pale grove
#

More or less yes

inland imp
gritty lily
#

no kittech. it's a good first step tho

inland imp
#

Well more or less

#

XD

indigo cloak
#

or it could mean there was a PR to the linter configs and nobody commented a disagreement on it

wheat sinew
inland imp
pale grove
#

The requirement is: you have experience working with the project, you have made contributions to the code or to the community

gritty lily
#

yeah. sci is our language wiz

pale grove
#

That's basically it

granite nimbus
#

However, I would say that "consensus" is not necessarily a "decision", nor was this distinction clear in Orion's messages. "Decision" heavily implies "official". If consensus is considered the official stance of neoforged, that's fine - well, except for the part where I was told that's not how that works

gritty lily
#

sadly luke, to actually make progress, the project has made LOTS of consensus decisions. like the one to exist for a start

granite nimbus
#

Sure, that's also fine

wheat sinew
#

in general, most teams work under consensus -- falling back to votes on contentious matters where consensus is unclear

granite nimbus
#

If it's a decision made by consensus, is it or is it not an official view of the neoforged team?

gritty lily
#

exactly. votes, and especially community votes, should be the exception, not the rule of everyday business sci

spice sphinx
granite nimbus
#

Because I've been told conflicting stuff, so some clarification would do a world of good in general

gritty lily
#

generally, it's not the official position, no. because the project isn't a person, and can't have opinions

#

the project can be forced to have an opinion by holding a meeting to make it have one.

#

that involves votes and quorums and other stuff

outer steeple
inland imp
#

But I think we layed out the arguments against it decently well

#

Especially since this was already a topic we discussed when we forked

gritty lily
#

yeah. it should be in the governing docs.

inland imp
#

And I used the term "corrected" because luke put value on your opinion, to indicated that your opinion would mean that my statement above were I used the royal we, was factually incorrect, in the sense that it had not been decided.

gritty lily
#

generally, we act and work on consensus. votes are used to try and decide on topics where there is clear differences of opinion. the SC vote is overriding when the maintenance community cannot make a decision.

inland imp
#

I remember there is a document on this

#

hold on

outer steeple
#

it does seem like only part of my concern was supposedly addressed, i haven't seen any mention of the first part which is what i based my entire argument to begin with - team pollution

gritty lily
#

soliciting community feedback is often a useful part of the maintenance decisionmaking. but that's ultimately something that that team should decide on the weight of and importance associated with it.

#

what do you mean team pollution? because we've added new members?

inland imp
gritty lily
#

why is that a problem?

inland imp
#

And we are growing the group

gritty lily
#

ah. more like clearing the weeds LOL

#

like me 😄

inland imp
#

So there is an argument for "pollution", at least that is how I interpretted it

#

Did I do that wrong maaty?

outer steeple
gritty lily
#

give them a "retired maintainer" role, that has no contributing power.

pale grove
#

Works for me

#

I think we wanted to do that ages ago

inland imp
pale grove
#

Someone go filter through the roles.

inland imp
#

Or some reference to Gandalf ?!?

wheat sinew
#

how old is old

gritty lily
#

let's enshrine that in the governance. contribute annually

#

a year

pale grove
#

We should also have the moderator team elect a new moderator lead

wheat sinew
#

based on last commit to neoforged?

gritty lily
#

since they have contributed in the discord or github

inland imp
wheat sinew
#

we should veer this discussion off of this thread and somewhere more... not-#1105595318197825557

inland imp
#

I thought I saw him post like within the last week?

pale grove
#

He was a temporary appointment by me, not elected by the moderators

inland imp
gritty lily
#

ok

pale grove
#

The moderators may choose to keep him

swift stream
#

i thought he was elected?

pale grove
#

Nope.

inland imp
pale grove
#

I appointed him

inland imp
#

I could have sworn he was elected.....

viscid mangoBOT
#
thecurle

[Reference to](#moderation-private message) #moderation-private [➤ ](#moderation-private message)Current votes: 2 for ashers, 3 for daemon, 1 for sci.

shroomdog27 referenced ·
swift stream
#

don't gaslight me

pale grove
undone bolt
#

wait we can see that?

pale grove
#

If someone links it yes

swift stream
#

no, but the bot can

pale grove
#

You need a message link

undone bolt
#

yes, that's what I mean

gusty dove
#

is it possible to predict message IDs with any level of accuracy

#

probably a #squirrels-🦊 question

charred sluice
#

not to any practical extent

pale grove
charred sluice
#

even if you guess one right, you don't know any surrounding context

inland imp
pale grove
#

It's my DMs with sci

#

That's why I pinged him

swift stream
#

imagine DMing people

#

couldn't be me

outer steeple
inland imp
pale grove
outer steeple
#

well there was also that dm group in which we also discussed that

#

but given you just cursed sci for making you remember a convo in an i assume inconfortable context..

pale grove
#

No it's a different thing entirely

outer steeple
#

i won't remind you thinkies

pale grove
#

It's completely different to anything we talked about maty

#

It was personal between me and sci.

wheat sinew
#

i mean, my concern was valid at the time thinkies

pale grove
#

It still is

wheat sinew
#

yea

outer steeple
#

then can i bring up that DM group? do you want me to? harold

pale grove
#

You can but it's not relevant whatsoever

#

Again, this was personal between me and sci

outer steeple
#

smh my head

#

anyways