1 |
Hi, |
2 |
|
3 |
Michał Górny: |
4 |
> Hello, everyone. |
5 |
> |
6 |
> I'd like to highlight a major problem with devmanual. For a basic |
7 |
> policy & developer documentation thingie, it's quality is so-so at best. |
8 |
> A lot of stuff is missing, lots of things are outdated or even |
9 |
> incorrect. Not many people are contributing, and those who try quickly |
10 |
> resign. |
11 |
> |
12 |
|
13 |
First of all, thank you for trying to get things fixed. |
14 |
|
15 |
> I have been very patient with this. However, my pressure has just risen |
16 |
> dangerously, and I think it's time to lay my frustration down on this |
17 |
> list. Maybe this will finally change something because my supplications |
18 |
> were unsuccessful so far. |
19 |
> |
20 |
|
21 |
I wish you communicated this particular frustration clearly before it |
22 |
made you very angry. |
23 |
|
24 |
> So a typical case of contributing to devmanual looks like this: |
25 |
> |
26 |
> 1. You put an effort to make a good patch. You submit it and wait. |
27 |
> |
28 |
> 2. Usually, after 2 weeks you get review, with a lot of grammar |
29 |
> nitpicks. I get that having nice pretty words is important, so I apply |
30 |
> them. If I have also tried to keep a nice history, I end up putting |
31 |
> the requested changes in appropriate commits. This usually takes |
32 |
> as much time as the original change but sure, worth it. |
33 |
> |
34 |
|
35 |
If you don't want me to review the grammar of the PR, feel free to tell |
36 |
me. You can ask me to focus specifically on certain aspects of it. I'm |
37 |
used to reviewing academic papers, so I do it the way I'm used to. I |
38 |
think this is a miscommunication on our part. |
39 |
|
40 |
> 3. If you're unlucky, you're told that you're using the wrong formatting |
41 |
> style. For example, you used the style of the preceding section which |
42 |
> is wrong. Or tyle style from style document which is apparently also |
43 |
> wrong [1]. But don't worry, after having to reformat a major change |
44 |
> twice you learn to remember the style acceptable by current devmanual |
45 |
> project people. |
46 |
> |
47 |
> 4. You wait again. With some luck, this time less than two weeks. Then |
48 |
> you learn you need to do more grammar changes. Possibly to stuff you've |
49 |
> already changed before. Fixing already takes more time than starting |
50 |
> from scratch. |
51 |
> |
52 |
> 5. Eventually, you discover you can't even properly merge the changes |
53 |
> back into your commits because the devmanual developers made you start |
54 |
> changing stuff you didn't touch in the first place. |
55 |
> |
56 |
> Then you look at 'git log' and top your frustration with the fact that |
57 |
> person who just made you waste another total of 4 hours to |
58 |
> unsuccessfully try to update an important document so that it doesn't |
59 |
> list practices we don't do for 10+ years, has not made a single change |
60 |
> himself in 2 years! |
61 |
> |
62 |
|
63 |
It's true that I haven't been able to author much content to devmanual |
64 |
recently. If you look at the same log though, I'm still one of the few |
65 |
people who commit to the repo. I at least try to review patches and |
66 |
commit them with what little time I have. |
67 |
|
68 |
> No offense intended. I understand people don't have much time. I can |
69 |
> understand that people can't even find time to review stuff and get it |
70 |
> merged within less than a month. But if you don't have time yourself, |
71 |
> why do you keep behaving like everyone else must have tons of free time |
72 |
> to get everything perfect for you? |
73 |
> |
74 |
> I'm going to be blunt here. If you applied suggested changes yourself |
75 |
> instead of writing them for me to do, you'd save a lot of time for us |
76 |
> both. Or if you just merged it and fixed it yourself afterwards. |
77 |
> Or accepted the fact that everything doesn't have to be perfect, |
78 |
> and reasonably correct documentation with imperfect grammar is better |
79 |
> than obsolete useless documentation that also has imperfect grammar just |
80 |
> because it was written before your time. |
81 |
> |
82 |
|
83 |
And I can do that for you, if you simply communicate this to me. If you |
84 |
just want me to do a high level overview of the patch, whether the |
85 |
information is correct, and fits the section, just tell me. I don't |
86 |
intend to behave in the way you describe. I'm sorry if I come off that |
87 |
way to you. |
88 |
|
89 |
I spend the time to point out those fixes anyway. It's easier for me to |
90 |
just fix it too. I do it out of my respect to you, so you don't feel |
91 |
like I'm changing your work arbitrarily. |
92 |
|
93 |
> That's all. I've been meaning to write this multiple times but I've |
94 |
> instead decided to cool down and spend another hours just to get |
95 |
> the work done. Just so I would have a good document to give our proxied |
96 |
> maintainers to read, or so I wouldn't have to explain them why our |
97 |
> documentation is wrong about every third thing. This time I'm saying |
98 |
> enough. |
99 |
> |
100 |
> Most of my pull requests were apparently approved, so they might be |
101 |
> finally merged some day. The update to mirrors [2] still needs |
102 |
> requested changes applied, so if you someone wants to take it over, |
103 |
> please do. The PR on upstream licenses [3] is still waiting on the main |
104 |
> review. |
105 |
> |
106 |
|
107 |
The PRs usually get stalled because I try to get at least one more |
108 |
developer to ack the changes before I merge. There are PRs that I |
109 |
approved, and are still waiting for another ack. Outside of that, I'm |
110 |
willing to change our workflow in a way that's more comfortable for you. |
111 |
|
112 |
> That's all. I guess it's the place where you suggest how we can fix |
113 |
> this mess. |
114 |
> |
115 |
> |
116 |
> [1] https://github.com/gentoo/devmanual.gentoo.org/blob/master/appendices/contributing/devbook-guide/text.xml |
117 |
> [2] https://github.com/gentoo/devmanual.gentoo.org/pull/110 |
118 |
> [3] https://github.com/gentoo/devmanual.gentoo.org/pull/109 |
119 |
> |
120 |
|
121 |
-- |
122 |
gokturk |