Re: [Tails-dev] Proposal: Redmine workflow change

2019-10-29 Thread anonym
intrigeri:
> Hi,
> 
> intrigeri:
>> So I propose that we drop the "QA Check" field and instead, introduce
>> a "Needs Validation" status.
> 
> This proposal from March 24 was implemented on June 2.
> 
> Any feedback about how this change impacted your work so far?

100% optimization, 0% loss of value! 10/10! :)
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.


Re: [Tails-dev] Proposal: Redmine workflow change

2019-10-24 Thread sajolida
intrigeri:
> intrigeri:
>> So I propose that we drop the "QA Check" field and instead, introduce
>> a "Needs Validation" status.
> 
> This proposal from March 24 was implemented on June 2.
> 
> Any feedback about how this change impacted your work so far?

Very fine change!

-- 
sajolida
Tails — https://tails.boum.org/
UX · Fundraising · Technical Writing
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.


Re: [Tails-dev] Proposal: Redmine workflow change

2019-10-24 Thread intrigeri
Hi,

intrigeri:
> So I propose that we drop the "QA Check" field and instead, introduce
> a "Needs Validation" status.

This proposal from March 24 was implemented on June 2.

Any feedback about how this change impacted your work so far?

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.


Re: [Tails-dev] Proposal: Redmine workflow change

2019-06-02 Thread intrigeri
intrigeri:
> intrigeri:
>> I'll wait (at least) one more week and if there's no strong objection,
>> I'll implement this proposal.

> I'm doing this today. Expect tons of notifications from Redmine.

Done!

Context:
https://lists.autistici.org/message/20190324.103611.7aa3cabe.en.html

Corresponding doc changes: 3a5f3861..3fdce88

I've updated all the Redmine custom queries I had access to. If you
have created custom queries that you've made visible only by yourself,
you may need to update them yourself.

I'll make sure the corresponding CI code updates I've pushed
work fine.
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.


Re: [Tails-dev] Proposal: Redmine workflow change

2019-06-02 Thread intrigeri
intrigeri:
> I'll wait (at least) one more week and if there's no strong objection,
> I'll implement this proposal.

I'm doing this today. Expect tons of notifications from Redmine.
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.


Re: [Tails-dev] Proposal: Redmine workflow change

2019-04-12 Thread segfault
Hi,

intrigeri:
> anonym:
>> intrigeri:
>>> Given we now have "mentions" (@nickname) on our Redmine, for the
>>> majority of cases, when the requested info can presumably be provided
>>> cheaply and quickly, I think we should use mentions and not reassign
>>> the ticket. And when I'm mentioned, if I realize that providing the
>>> requested info needs will take me great amounts of work, I should
>>> do whatever works for me to track this work, be it on a new ticket
>>> or my personal offline organization tools.
> 
>> I quite like this feature and have set up filter rules in my email
>> client for the resulting redmine notifications I receive so I don't
>> miss them. However, I wonder how this works out if you don't do
>> something like that. I also fear that the ad hoc tracking of
>> "mentions" that you propose above is easy to forget.
> 
> I think most of us are in one of these 4 situations:
> 
>  - They notice and track new incoming emails but don't pay much
>attention to tickets reassigned to them on Redmine (note that
>Redmine sends no notification to the new assignee).
> 
>Mentions help. Reassigning does not help (I've seen quite a few
>cases recently where it appears that the new assignee had no idea
>something was expected from them).
> 
>So dropping "Info Needed" is a no-op.

I fall into this category, *but* I think the "Info Needed" field is
still sometimes useful for me. While I at least take notice of all my
Redmine emails, I sometimes get a lot of them (because I also watch some
tickets which are not on my plate, but for which I would like to stay
up-to-date about the progress). And my tracking is not the best, I
sometimes forget to star an email that requires action by me. In this
case it does help if a ticket is assigned to me so that I see it when I
check my assigned tickets on Redmine (which I do rarely, but still).

But I also see that losing track of ones issue by assigning someone for
"Info Needed" is a problem. It would be nice if Redmine would support
multiple assignees for issues, which GitLab does support.

All in all I'm okay with trying to drop the "Info Needed" field and see
how it works out.

Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Proposal: Redmine workflow change

2019-04-12 Thread intrigeri
Hi,

I'll wait (at least) one more week and if there's no strong objection,
I'll implement this proposal.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Proposal: Redmine workflow change

2019-04-12 Thread intrigeri
Hi,

anonym:
> intrigeri:
>> Given we now have "mentions" (@nickname) on our Redmine, for the
>> majority of cases, when the requested info can presumably be provided
>> cheaply and quickly, I think we should use mentions and not reassign
>> the ticket. And when I'm mentioned, if I realize that providing the
>> requested info needs will take me great amounts of work, I should
>> do whatever works for me to track this work, be it on a new ticket
>> or my personal offline organization tools.

> I quite like this feature and have set up filter rules in my email
> client for the resulting redmine notifications I receive so I don't
> miss them. However, I wonder how this works out if you don't do
> something like that. I also fear that the ad hoc tracking of
> "mentions" that you propose above is easy to forget.

I think most of us are in one of these 4 situations:

 - They notice and track new incoming emails but don't pay much
   attention to tickets reassigned to them on Redmine (note that
   Redmine sends no notification to the new assignee).

   Mentions help. Reassigning does not help (I've seen quite a few
   cases recently where it appears that the new assignee had no idea
   something was expected from them).

   So dropping "Info Needed" is a no-op.

 - They regularly look at their Redmine plate but they won't notice
   incoming email Redmine sends them, unless they set up
   ad-hoc filters.

   Mentions don't help. Reassigning or creating a new subtasks helps.

   So dropping "Info Needed" + reassignment brings a regression.
   To mitigate this:

- We should strongly recommend these folks set up whatever
  filters they need to notice email our Redmine is sending them.
- Creating a dedicated subtask for the info request is an option
  in some cases (I'll discuss this below).
- To address the root cause of the problem and make email
  a communication option that actually works, we should gently
  suggest these folks to unsubscribe from sources of incoming
  email that they don't read, and that swamps them in an inbox
  they barely dare looking at. I guess that's part of self-care
  recommendations we could promote more visibly within Tails :)

 - They pay attention to their Redmine plate and to incoming email.

   All's well, no change here.

 - They don't pay much attention to their Redmine plate and don't
   notice incoming email from Redmine.

   No change here. No ticket tracking system will help. Only social
   processes, such as regular team meetings, have a chance to enable
   successful collaboration & communication.

> I just had a half-baked idea that might have some merit: say I work
> on ticket X and need info about "foo" from intrigeri. Then I just
> create a subticket Y of X called "Info needed: foo" and assign it to
> intri. When intri has posted the information about "foo" to X he can
> then mark Y as resolved.

That's surely a valid option in some cases, mainly: 1) when the
overhead of "just" creating a subtask is justified by the amount of
work needed to fulfil the info request; 2) for those of us who can't
afford paying attention to email Redmine sends them. I don't know how
much of our "Info Needed" usage fits into this category. I want to
keep this option in mind even though I'd rather first tackle the root
cause of the problem, because for (2) this option feels like
a workaround.

Cheers!
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Proposal: Redmine workflow change

2019-04-12 Thread intrigeri
sajolida:
> intrigeri:
>> So I propose that we drop the "QA Check" field and instead, introduce
>> a "Needs Validation" status.

> Good idea! Works for me.

:)

> What would happen to tickets that go back-and-forth between the main
> author and the reviewer? Would they stay in "Needs Validation" or go
> back-and-forth between "In Progress" and "Needs Validation"?

The latter, as per:

  And if the reviewer requests changes, they would set the status
  back to "In Progress".

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Proposal: Redmine workflow change

2019-03-25 Thread sajolida
intrigeri:
> So I propose that we drop the "QA Check" field and instead, introduce
> a "Needs Validation" status.

Good idea! Works for me.

What would happen to tickets that go back-and-forth between the main
author and the reviewer? Would they stay in "Needs Validation" or go
back-and-forth between "In Progress" and "Needs Validation"?

-- 
sajolida
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Proposal: Redmine workflow change

2019-03-25 Thread anonym
intrigeri:
> So I propose that we drop the "QA Check" field and instead, introduce
> a "Needs Validation" status.

Sounds much simpler, awesome! +1

> Given we now have "mentions" (@nickname) on our Redmine, for the
> majority of cases, when the requested info can presumably be provided
> cheaply and quickly, I think we should use mentions and not reassign
> the ticket. And when I'm mentioned, if I realize that providing the
> requested info needs will take me great amounts of work, I should
> do whatever works for me to track this work, be it on a new ticket
> or my personal offline organization tools.

I quite like this feature and have set up filter rules in my email client for 
the resulting redmine notifications I receive so I don't miss them. However, I 
wonder how this works out if you don't do something like that. I also fear that 
the ad hoc tracking of "mentions" that you propose above is easy to forget.

I just had a half-baked idea that might have some merit: say I work on ticket X 
and need info about "foo" from intrigeri. Then I just create a subticket Y of X 
called "Info needed: foo" and assign it to intri. When intri has posted the 
information about "foo" to X he can then mark Y as resolved.

Cheers!
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Proposal: Redmine workflow change

2019-03-25 Thread u
Hello,

On 25.03.19 10:10, Daniel Kahn Gillmor wrote:
> On Sun 2019-03-24 11:36:11 +0100, intrigeri wrote:
>> Thoughts?
>>
>> I'll be happy to implement this proposal.
> 
> I'm not a regular contributor, so you should weight my opinion very
> lightly, but this all sounds quite to me.
> 
> The more i see technical systems in actual use, the more i think that
> simpler tooling is better and more likely to be used effectively, even
> if it is not as nuanced.
> 
> The argument for nuance is that it can typically represent reality more
> closely than the simpler view.  But if, in practice, that nuance isn't
> widely understood, or is accidentally misused, then that particular
> advantage is actually a disadvantage.
> 
> Your proposal sounds simpler and therefore more likely to be accurate.

I'm all for simplifications of workflows :)

Cheers!
u.
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Proposal: Redmine workflow change

2019-03-25 Thread Daniel Kahn Gillmor
On Sun 2019-03-24 11:36:11 +0100, intrigeri wrote:
> Thoughts?
>
> I'll be happy to implement this proposal.

I'm not a regular contributor, so you should weight my opinion very
lightly, but this all sounds quite to me.

The more i see technical systems in actual use, the more i think that
simpler tooling is better and more likely to be used effectively, even
if it is not as nuanced.

The argument for nuance is that it can typically represent reality more
closely than the simpler view.  But if, in practice, that nuance isn't
widely understood, or is accidentally misused, then that particular
advantage is actually a disadvantage.

Your proposal sounds simpler and therefore more likely to be accurate.

 --dkg


signature.asc
Description: PGP signature
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Proposal: Redmine workflow change

2019-03-24 Thread intrigeri
Hi,

With the upcoming migration to GitLab in mind, while reading some
books, using a kanban board locally, and with the idea to make the
contribution process smoother for both newcomers & long-timers, I've
thought quite a bit about how we use tickets to organize our
work recently.

My main conclusion so far is: I want to make it easier to determine
and set the status of a ticket.

Currently, the status of a Redmine ticket is built from the
combination of "Status" and "QA Check"; it does not help that some of
these combinations make no sense at all. I've noticed that many of us
have a hard time managing these 2 fields, regardless of how long
they've been contributing to Tails; so this data is very often wrong.
This, plus Redmine limitations, makes it impossible at the moment to
have an overview of a set of tickets, grouped by their actual status
(defined by a combination of "Status" and "QA Check").

So I propose that we drop the "QA Check" field and instead, introduce
a "Needs Validation" status. So a ticket would typically go through
this journey:

 New → Confirmed → In Progress (once someone starts working on it)
 → Needs Validation (once it's deemed ready to be merged by the
 person/team who's been working on it) → Fix committed → Resolved.

And if the reviewer requests changes, they would set the status
back to "In Progress".

The only thing we lose along the way is QA Check = "Info Needed" plus
the associated reassignment dance. Removing that has only benefits
IMO:

 - This value is very often wrong because we forget to drop it and to
   reassign back, after providing the requested info.

 - Assigning a ticket to someone else + Info Needed, merely to get
   some input regularly causes trouble: it makes the task invisible to
   the person who's requesting the info, which makes it harder to
   organize their work — occasionally I'll be surprised when a ticket
   lands back on my plate after the info is provided. And if the
   requested info is not provided in a timely manner, WIP can be
   stalled for a long time, with no easy way for the requester to
   notice and decide whether they should move on without that info.

Given we now have "mentions" (@nickname) on our Redmine, for the
majority of cases, when the requested info can presumably be provided
cheaply and quickly, I think we should use mentions and not reassign
the ticket. And when I'm mentioned, if I realize that providing the
requested info needs will take me great amounts of work, I should
do whatever works for me to track this work, be it on a new ticket
or my personal offline organization tools.

Thoughts?

I'll be happy to implement this proposal.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.