Gentoo Archives: gentoo-dev

From: Tom Wijsman <TomWij@g.o>
To: gentoo-dev@l.g.o
Cc: rej@g.o
Subject: Re: [gentoo-dev] Response to a "friendly note" about changing bug reports
Date: Wed, 07 Aug 2013 12:15:29
Message-Id: 20130807141138.696df24f@TOMWIJ-GENTOO
In Reply to: [gentoo-dev] Response to a "friendly note" about changing bug reports by Jeroen Roovers
1 On Tue, 6 Aug 2013 23:46:08 +0200
2 Jeroen Roovers <jer@g.o> wrote:
3
4 > 23:37:25 <willikins> rej, you have notes! [21:13] <mrueg> Let me
5 > rephrase this: Just a friendly notice to please refrain from
6 > rephrasing bug summaries from "Stabilize ${P}" to "${P} stable req".
7 > This just adds unneeded noise to the bug. I don't want this on bugs
8 > I've reported or am assigned to.
9 >
10 > This is my equally short and "friendly" note: It's not going to
11 > happen. Forget about it. They are not "your" bug reports and anyone is
12 > actually /welcome/ to improve them. Get used to it.
13
14 This note doesn't really hold well; if two people, not necessarily the
15 reporter or assignee of a bug, want to do opposing improvements then
16 you get an edit war as a result. In mrueg's words, "unneeded noise".
17
18 The concern is valid; if a person is bothered by changes you make, that
19 person won't get used to those changes at all if they can be undone.
20
21 -> Why do you think there's only one way of doing it?
22
23 While I don't know how to search for such change; the last unneeded
24 noise I remember you doing to a bug is adding or removing the dot at
25 the end of a bug summary, doing nothing else to the bug.
26
27 There are sites, like Stack Exchange, where you are forced to edit
28 multiple characters and type out a summary that explains what you did,
29 as well as providing an easy rollback option; to avoid unneeded edits.
30 It's hand holding because almost anyone can edit on such site; from
31 what I've saw, it really works out well but shouldn't be necessary.
32
33 -> What does such small unimportant change gain you?
34
35 Not that I'm bothered, because that was just one extra mail; but
36 repetitively doing stuff similar to this generates much more than just
37 one extra mail, so I get to see multiple mails of this type over the
38 place. And while you're just one person, there are others too; it adds
39 up, up to the point that it's really just a waste of time.
40
41 -> Why do you think the burden generated from this is worth it?
42
43 > To get technical on the "improvement" bit, we have agreed time on time
44 > that stating the atom and then the action is the way to go.
45
46 Who is "we"? Why is it the "way to go"? If you use such language you
47 need to link to the actual evidence; otherwise, despite the reasoning
48 you give, it will be seen as an authoritative contradiction instead of
49 an actual counterargument. You and I know when that was decided, but a
50 new developer doesn't; well, at least I know of the last time it did:
51
52 http://article.gmane.org/gmane.linux.gentoo.devel/85647
53
54 You do the same thing there with "we agreed a little while ago"; and
55 upon request of djc, phajdan.jr and myself there appears to have been
56 no response, only to later be answered by someone else that knows:
57
58 http://www.gossamer-threads.com/lists/gentoo/dev/173889
59
60 As far as I know, there is no requirement to read the entire mail
61 archives and this is undocumented; so, as it is not always as easy to
62 search matters like this (wrong search terms, result on last page, ...)
63 it would help a lot if things were referred to.
64
65 Otherwise people might simply ignore your statements, discuss it again
66 or just apply the opposite changes; neither of which is what you want.
67
68 > The main reasons is that it helps people who need to regularly
69 > read /lists/ of bug summaries sort them better. Until we get a
70 > specific [Atoms] field implemented, it will need to stay this way.
71
72 Has someone already filed a bug with a request for this?
73
74 > Besides the finer technical points of bug maintenance, it simply
75 > infuriates me that anyone would think of bug reports in the
76 > possessive.
77
78 It's actually more natural. Again using Stack Exchange as an example, a
79 lot of question titles there tend to be an actual question because
80 some people think it reads much better; I don't think that this is
81 necessarily a good idea for bug summaries, but just want to point out
82 that it is a possibility.
83
84 Putting the atom first focuses on a summary that feels a bit more
85 machine readable; whereas if you put it into a sentence, it gives a bit
86 more freedom to express it as an actual sentence. It's weird to think
87 about the other way if you're used to one way; but, I consider the end
88 result rather equal, which you probably do as well as it is easy to
89 change between the formats.
90
91 We can go on for this for a long time, but that would be bike shedding;
92 s,o I just wanted to demonstrate that there are at actually at least two
93 sides on the matter. As agreed in earlier threads, the list readability
94 is indeed a valid reason until a more proper field becomes implemented.
95
96 Besides that, I think there are much bigger concerns; let me take a
97 random bug title "dnsmasq systemd unit file improvement" and point out
98 that it bothers me more not knowing what the improvement is, let's say
99 you have another bug like this then how would you tell them apart?
100
101 Knowing which improvements the bug consists of, helps to process the list.
102
103 > This is not the way to improve the distro. You're on the
104 > wrong track there. And you weren't being friendly.
105
106 Have you friendly explained the bug list reasoning to him before posting
107 this to the mailing list? Your mail reads more like a personal message
108 to him; this mailing list is for technical discussions, this is none.
109
110 --
111 With kind regards,
112
113 Tom Wijsman (TomWij)
114 Gentoo Developer
115
116 E-mail address : TomWij@g.o
117 GPG Public Key : 6D34E57D
118 GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D

Attachments

File name MIME type
signature.asc application/pgp-signature