Re: RFC: Representing "image needed" in Taiga

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



So I thought about this, and:

The image can be basically done at any state — so that goes against
creating a new column for that.

Anything that's not visible in the Kanban view, I wouldn't do, because
there is no simple way to list articles that need an image. Yes, you can do
filter the Kanban view, but that's a bit clunky in Taiga.

I'd go with the label. We don't use them for anything, so if there is a
label on a card, it means it needs an image. A disadvantage of this is that
it's not obvious that new cards need to be labeled, but the editors could
take care of that I believe.

About using both labels and custom fields, that seems like a source for
errors and too much unnecessary clicking.

So let's go with the label?

On Fri, Nov 8, 2019 at 10:55 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote:

> On Fri, Nov 8, 2019 at 4:01 PM Ryan Walter <rwalt@xxxxx> wrote:
> >
> > Also, if creating an Image is a task of itself. Would it be reasonable
> to consider it its own card and then have that card reference the original
> article spec? A image workflow is a bit similar from my understanding.
> Needs to be created, viewed, and potentially edited.
>
> The workflow for images is, in practice, much simpler than articles.
> Someone makes it and it's done. Conceivably there can be some
> back-and-forth, but that doesn't happen much in practice. I wouldn't
> want to have separate user story cards because then it becomes really
> hard to tie them together.
>
> On Fri, Nov 8, 2019 at 4:05 PM pmkellly@xxxxxxxxxxxx
> <pmkellly@xxxxxxxxxxxx> wrote:
> >
> > > 2. Use a tag
> > > 3. Use a custom field
>
> > How about a combination of 2 and 3? You get the high visibility flag to
> > open the card and the state can be shown. The color could explained very
> > briefly at the top of the kanban page perhaps "Blue cards need image".
> >
> That would get us the best of both worlds, but I'm worried it would
> result in indeterminate state when the editor updates one but forgets
> to update the other.
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> _______________________________________________
> Fedora Magazine mailing list -- magazine@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to magazine-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/magazine@xxxxxxxxxxxxxxxxxxxxxxx
>


-- 

Adam Šamalík
---------------------------
Senior Software Engineer
Red Hat
_______________________________________________
Fedora Magazine mailing list -- magazine@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to magazine-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/magazine@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora Users]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Devel]     [EPEL Announce]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Review]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [ET Management Tools]     [Yum Users]     [Fedora Art]     [Fedora ARM]

  Powered by Linux