Replies: 8 comments 29 replies
-
|
Voting must be done via mailing list, this poll is not valid. |
Beta Was this translation helpful? Give feedback.
-
Yes that's what I mean, with "if we announce them on the list", e.g. if we send a a message to the devlist with a link to the (internal) github discussion asking for a vote it might be "official" enough, but lets see if Wayne Beaton can give some guidance here. |
Beta Was this translation helpful? Give feedback.
-
I think we can't as the names of the votes are not visible and only committers have a valid vote. Using polls could lead to "invite your friends to the voting party" polls. |
Beta Was this translation helpful? Give feedback.
-
|
@vogella please see https://github.com/orgs/eclipse-equinox/teams/eclipse-equinox-committers what is only accessible by equinox commiters. |
Beta Was this translation helpful? Give feedback.
-
|
TL;DR: I believe that in this case, votes must be held on the dev list and that only committer votes count. The Eclipse Foundation Development Process (EDP) is silent on where votes must take place. While it is hinted that committers are the ones who vote, the EDP does not explicitly exclude a project deciding to include others in a vote on matter unrelated to governance. That is, notwithstanding limitations introduced in the TLP's charter, in the general case it's entirely up to the project to determine what open and transparent channel they choose to use for a vote, and whose votes are binding, in matters that are unrelated to governance. Having said all that, the Eclipse TLP Charter, states this:
So... as I stated above, I believe that in the case of open source projects operating under the purview of the Eclipse PMC, votes must be held on the dev list and that only committer votes count. HTH. |
Beta Was this translation helpful? Give feedback.
-
Yes and no. The TLP charter must be approved by the board of directors. But the way that we operate is that the PMC drafts an update and we take it to the board for approval. So, yes... you should talk to the committer rep to make at least socialise the changes that you want to make. I'll admit that I haven't read the EDP from top to bottom in some months, but I'm pretty sure that we don't need any changes there. Do feel free to correct me if I'm wrong. As I dig deeper... the standard charter (version 1.2), which most other TLP charters (not the Eclipse TLP Charter) include by reference (the Eclipse TLP Charter was the template from which the standard charter was created), has the same use-the-mailing-list-for-votes as the Eclipse TLP charter (which means that basically all of our projects are obligated to use their dev list for votes). I've opened an issue to start work on a version 1.3 that removes this requirement. I'm thinking that we're pretty far off topic for this issue, so I'll update that issue with far more information about the process than anybody cares to know. |
Beta Was this translation helpful? Give feedback.
-
|
If we just tagged an issue as stale, then those who don't want to see stale issues could filter them out... |
Beta Was this translation helpful? Give feedback.
-
So you think adding more bot messages will make things better? ;-) By the way you can configure it. e.g. chose "Watch > Custom > ... " and I already mentioned it in the past discussions, sure a reminder is good but an automatic reminder is bad as it just adds noise and we better commit to a way to handle issues, e.g. having a "bugfixing week" on each release or even dedicate the December release to bugfixing/triaging. Also there are freeze periods that could be used to just get through the list of bugs and probably leaving a suitable (saved) comment, adding labels or even closing outdated or irrelevant stuff |
Beta Was this translation helpful? Give feedback.
-
That's actually my feeling here as well. The issue is not leaving bugs open or closing them as I believe this has no impact on the team productivity nor code quality; it's more about communicating fair expectations users can have and reasons why an issue is ignored and how this could be remediated. As the important part is communication, more messages do actually help. |
Beta Was this translation helpful? Give feedback.
-
I honestly do not count automatic messages as "communication" ... they are just useless, if we ant to communicate something to the user, we should do it right now when he open a ticket, e.g. with a suitable issue template and not let them create tickets and later some bots chatting with them... |
Beta Was this translation helpful? Give feedback.
-
That's one POV, but our former experience with automatic messages (with auto-close, and when we migrated away from bugzilla, or even dependabot messages, or "stale" messages in other projects...) do demonstrate that it's not a generality and that those messages to generate reaction, that can sometimes be channeled into a contribution.
Everyone agrees here. But people who are able to give the answer may be on holiday, busy with something else, or just may miss the ticket by inadvertance as it's one out of 100... So while everything and everyone should be perfect, we also need realism and pragmatism and embrace the fact that things and people are not perfect. A bot can help compensating those flaws. |
Beta Was this translation helpful? Give feedback.
-
That's a different story, as this adds at least some value, so if we have a
As mentioned above a bot can't fix anything of those, and the cases where really something happens are rare, I'm happy not getting these stupid auto-close messages filling my mailbox even more and 1 out of 100 creating an actual reaction... |
Beta Was this translation helpful? Give feedback.
-
|
Instead of closing the issue we could add an automated message (and a label if it helps) that explains friendly why this issue maybe has not been fixed. |
Beta Was this translation helpful? Give feedback.
-
|
I support "stale" labeling and bot labeling and closing of stale issues. Closed stale issues still exist and can be found with search. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe we can auto-close all issues right after creation because the could be found by the search anyways? ;-) If we do not look at open issues, do we really expect someone will look at (auto-) closed issues if they maybe relevant?? |
Beta Was this translation helpful? Give feedback.
-
|
My point is that closing stale issues does not mean they are sent down the memory hole. They still exist so that when someone else encounters the same or similar issue, their search will find the closed stale issue. |
Beta Was this translation helpful? Give feedback.
-
|
I personally am _for_ auto tagging and then closing after some period of
inactivity.
This has two effects:
- it keeps the project from looking overly decrepit with hundreds of bugs
that no-one is interested in. (I've enjoyed the bugzilla auto close feature
since it was implemented)
- it prompts people who may not had time or interest at the time of
creation an opportunity to react when they see the stalebot do its job
This is a practical need on a project of this magnitude where few
individuals have a complete clarity on all the parts it holds. There are
valid reasons for why an issue created at any given time is not treated at
that moment and/or eventually go out of scope. This is just a fact.
…On Thu, Jun 23, 2022 at 11:25 AM Christoph Läubrich < ***@***.***> wrote:
Maybe we can auto-close all issues right after creation because the could
be found by the search anyways? ;-)
If we do not look at *open* issues, do we really expect someone will look
at (auto-) closed issues if they maybe relevant??
—
Reply to this email directly, view it on GitHub
<#51 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABD2TGLBIX7DBTUPN66BLDVQR6YLANCNFSM5ZIJUMPA>
.
You are receiving this because you are on a team that was mentioned.Message
ID: ***@***.***
com>
--
*Raymond Augé* ***@***.***)
Senior Software Architect *Liferay, Inc.* ***@***.***)
OSGi Fellow, Java Champion
|
Beta Was this translation helpful? Give feedback.
-
Does it help if only a bot is "interrested" in the bugs? Do we use bugtracker for tracking bugs or for some kind of powerpoint sheet to show how "active" the project is and how many issues where "solved"? |
Beta Was this translation helpful? Give feedback.
-
|
I've said this already, but getting events on stale bugs, either with a label or comment or otherwise, I think helps inform ones that are listening and alerts them of the issue again. I've often taken action when I see this type of event. Just leaving the issue there with no event indefinitely doesn't seem like it would be helpful to anyone. |
Beta Was this translation helpful? Give feedback.
-
|
Does it help if only a bot is "interrested" in the bugs? Do we use
bugtracker for tracking bugs or for some kind of powerpoint sheet to show
how "active" the project is and how many issues where "solved"?
It is unfortunately very common for people to use issues in this way:
me: "Ah, I must remember that I want to do this task on that thing because
it's super important" -> new ticket...
others: "Is that really necessary?..."
... maybe debate ensues and I convince everyone it's important... but I
will work on it later when I have time...
... one year later no work was done.
bot (if it was present): shall I close this issue you opened
<implied-snark>clearly it wasn't that important</implied-snark>?
Almost every Eclipse bugzilla project is evidence of this. And it _HAS_ a
stalebot enabled!
I was happy when projects I was/am involved with had less than 50 open
issues at a time (and don't forget this was/is a mono repo where 90% of
modules I really don't have any use for and so won't likely interact with,
and at least that many issues as well).
…On Thu, Jun 23, 2022 at 12:02 PM Christoph Läubrich < ***@***.***> wrote:
it keeps the project from looking overly decrepit with hundreds of bugs
that no-one is interested in
Does it help if only a bot is "interrested" in the bugs? Do we use
bugtracker for tracking bugs or for some kind of powerpoint sheet to show
how "active" the project is and how many issues where "solved"?
—
Reply to this email directly, view it on GitHub
<#51 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABD2TDGIS63AEQLV4KUISTVQSDBBANCNFSM5ZIJUMPA>
.
You are receiving this because you are on a team that was mentioned.Message
ID: ***@***.***
com>
--
*Raymond Augé* ***@***.***)
Senior Software Architect *Liferay, Inc.* ***@***.***)
OSGi Fellow, Java Champion
|
Beta Was this translation helpful? Give feedback.
-
|
We could shut down issues completely and only accept pull requests. 🥲 But then maybe we would need an auto-close process for those too when no one cares enough to process them. 😱 |
Beta Was this translation helpful? Give feedback.
-
|
Maybe we can auto-close eclipse-projects if the reach > 💯 issues :-D |
Beta Was this translation helpful? Give feedback.
-
|
From my perspective auto-closing has not proven much benefits over the past years we have enabled it. I therefore now started a new poll if we still want to keep it or drop it: so please vote if you are interested in the topic (silence will most likely be interpreted as agreement to disable it). |
Beta Was this translation helpful? Give feedback.
-
Equinox has used autoclosing of bugs in the past for bugzilla.
@eclipse-equinox/eclipse-equinox-committers please give an indication if you think we should do the same for Github, e.g. as proposed in #50
Also non-commiters please give us a hint what you think about it by casting a vote.
8 votes ·
Beta Was this translation helpful? Give feedback.
All reactions