1 |
On 24/03/2013 15:40, Peter Stuge wrote: |
2 |
> Markos Chandras wrote: |
3 |
>> The masks are sort of announcements as you have 30 days to revert that |
4 |
>> decision. |
5 |
> |
6 |
> You don't seem to recognize the quite significant psychological |
7 |
> impact of you having already made the decision, compared to, say, |
8 |
> having an actually inclusive package removal process. |
9 |
> |
10 |
> Bugzilla does not count as inclusive in this case. |
11 |
> |
12 |
> I mean something like a process where users who have this package |
13 |
> installed are notified about the change in status, as opposed to |
14 |
> having to monitor a developer mailing list or portage.mask in order |
15 |
> to get those news. It would probably be a part of emerge --sync. |
16 |
> |
17 |
> I think that might do far more good than any web page. |
18 |
> |
19 |
> You might argue that such a thing is completely outside your |
20 |
> department, but please consider that what you do can't be seen |
21 |
> in isolation, because users don't care at all about the isolated |
22 |
> particulars which result in their package being masked and cleaned, |
23 |
> they just see that the package is gone one day. You should care |
24 |
> because what you do is the trigger for that user experience. |
25 |
> |
26 |
> Improving UX should be your priority too, even if it isn't formally |
27 |
> part of what you do. (Should be everyone's priority.) |
28 |
|
29 |
We have 5 "statuses" for packages |
30 |
|
31 |
- stable |
32 |
- unstable |
33 |
- masked by no keyword |
34 |
- hard masked |
35 |
- gone |
36 |
|
37 |
You are proposing one more: |
38 |
|
39 |
- stable |
40 |
- unstable |
41 |
- masked by no keyword |
42 |
- candidate for hard mask |
43 |
- hard masked |
44 |
- gone |
45 |
|
46 |
I see that as pointless, the extra category buys you nothing (except as |
47 |
one more thing users can ignore). Even if you prompt the user during |
48 |
emerge to accept the candidate packages after reading the reason, you |
49 |
have not actually done anything different from hard masking it. The |
50 |
effect is the same - the user tweaks the system to allow the package to |
51 |
be emerged, user gets on with life. And one day the package is gone. |
52 |
|
53 |
Masking already accomplishes everything you propose, which is to |
54 |
communicate "there is something wrong with this package and it is in |
55 |
danger of leaving the tree. To get it out of this state, you need to |
56 |
take action". |
57 |
|
58 |
As for what constitutes "take action", well that is highly variable and |
59 |
isn't something that easily submits to categorization. Better to give |
60 |
the reason in a plain text comment with a link where interested users |
61 |
can go to start the rescue process. |
62 |
|
63 |
You also didn't give any examples of how "inclusive" could work. |
64 |
|
65 |
-- |
66 |
Alan McKinnon |
67 |
alan.mckinnon@×××××.com |