[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Participation (was: Re: [virtio-comment] RE: [virtio-dev] RE: [PATCH v12 03/10] content: Rename confusing queue_notify_data and vqn names)
On Mon, Apr 17 2023, "Michael S. Tsirkin" <mst@redhat.com> wrote: > I am not saying don't give feedback but I'm saying please help us > all be more organized, feedback time really should be within a > day or two, in rare cases up to a week. Given that there are things like weekends, public holidays, etc. one day does not look reasonable; while it certainly makes sense to continue if no feedback is forthcoming for a few days, not accounting for the fact that this is not the exclusive job for most/any of us is just a fast track to either burnout or people dropping out of virtio standardization altogether. > And I'd like to remind everyone if you are going away you are supposed > to report a leave of absence. Well... "Each request shall be made by sending an email to the TC mailing list at least 7 days before the Leave is to start." is probably not going to work for many cases. (Also, in any other community I'm participating in it is expected that you just might not be there or have time to work on it every week -- I've always seen that leave of absence thingy as something for a really long vacation or for something like parental leave, for which the max 45 days is really too short...) Not to mention that it applies to voting, not to participation on the lists. > TC's that have meetings just take away voting rights from someone who > does not attend two meetings in a row. We do it by ballot so this does > not apply, but I think we should set some limits in group's bylaws, > anyway. Ideas on formalizing this? If not we can just have informal > guidelines. There's of course a flip side to this. Some patches > seemingly go through two versions a day. Keeping up becomes a full time > job. We'd need a guideline for that, too. What do we actually expect from TC members? "Reply to emails" is not part of any formal requirement AFAICS (and not all TC members do participate on the lists on a regular basis anyway). The requirement is only to vote on the ballots, and there you're completely free to vote "abstain", so you can always squeeze in voting even if you're not able to participate otherwise. I think that's fine. "If I don't get a reply after $NUMBER_OF_WORKING_DAYS, I'll assume I can proceed as I think fit" is a reasonable assumption to make, e.g. to request a vote. Not sure if/how to formalize that. Also, how is this supposed to work if the original author doesn't reply to comments? Should the proposal be considered abandoned? I agree that patch reposting is happening much too fast in some cases. Not sure how to formalize that, either. Can we please just be more mindful of that? Reviewing time is not free. If I'm trying to do a timely review of something and constantly see new versions while I'm not finished yet, I do not feel like my feedback is actually valued. > I also feel high latency is one of the reasons people are beginning to > ask to split into subcommitees where they won't have to deal with this > kind of thing. Let's try to keep the latency low, please. I think there's multiple things to unpack here. - The very common strain of limited reviewer time. This seems to be an issue nearly everywhere. Encouraging more review helps; but if review and ensuing discussing turns into a time sink, it just cannot be handled at a reasonable activity level anymore. - Latency due to missing feedback. Can be solved by just requesting a vote if no feedback is forthcoming in a reasonable time frame. - Latency due to missing reaction to feedback. This means the proposal just doesn't make any progress. The onus is on the submitter here. - Conflicting approaches favoured by different people. This cannot be resolved in a formal way; either people need to be convinced that a certain approach will work, a middle ground found, or a way worked out that the different approaches can co-exist. In any case, this usually means long discussions which can be very frustrating, but unless we want to bulldoze over some people this is something we'll have to live with. [Personally, I think this is the worst contributor to frustration, and not something that can be solved by subcommittees.] - [I'm also not happy with the tone of some emails I've been seeing. I won't point to them in order not to stir up things that have already calmed down again.]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]