Qgil added a comment.
One problem with this approach is that most probably there will not be projects
only for bugs. Within a projects you will have bugs, development of new
features, and perhaps even other tasks taking time from developers, like
writing documentation of running a tutorial in
Legoktm added a comment.
Ok, can we please start simple before deciding to turn actually useful things
off?
Here's an easy one, have the mailing list (or is this possible to do on Phab's
side?) reject all mail with the following header and value:
X-Phabricator-Mail-Tags: maniphest-cc
That
Aklapper added a comment.
[off-topic I guess]
! In T763#15165, @Qgil wrote:
I see that a #Bug_Report tag exists.
If there was such a tag in here, then there isn't anymore (I don't know the
story behind).
IMHO it is //good// that the tag is gone if we don't plan to bikeshed on types
of
Qgil added a comment.
! In T763#15610, @Aklapper wrote:
! In T763#15165, @Qgil wrote:
I see that a #Bug_Report tag exists.
#Bug-Report
It was created with a space, and I applied the guidelines. :)
TASK DETAIL
https://phabricator.wikimedia.org/T763
REPLY HANDLER ACTIONS
Reply to comment
jeremyb-phone added a comment.
! In T763#15613, @valhallasw wrote:
Discard will silently discard, and should therefore be usable in this
situation.
citation needed. (or test it)
TASK DETAIL
https://phabricator.wikimedia.org/T763
REPLY HANDLER ACTIONS
Reply to comment or attach files, or
chasemp added a comment.
What if we made an extension that added the list for any project with the
bug symbol? Could have a generic one 'bug' but then then it allows better
taxonomy. Unless there is a better use for the bug symbol.
TASK DETAIL
https://phabricator.wikimedia.org/T763
REPLY
mmodell added a comment.
Ok I think we should create a 'bug' tag (project)... the only problem I can see
is that users unfamiliar with out conventions would most likely omit the 'bug'
project when submitting bug reports. We could handle this in triage by simply
adding the tag when it's
chasemp added a comment.
a good idea but I am hesitant to do this before bugzilla migration as I think
it encourages something we don't wantmaybe wikibugs-l shouldn't get
anything from phab until then?
TASK DETAIL
https://phabricator.wikimedia.org/T763
REPLY HANDLER ACTIONS
Reply to
chasemp added a comment.
! In T763#14142, @jeremyb wrote:
Does it have to be a single project to decide whether or not it goes to the
list?
it could be a list, right now it's simply new tasks CC the list. We can pair
that down how we want per herald.
TASK DETAIL
Chad added a comment.
! In T763#14145, @chasemp wrote:
maybe wikibugs-l shouldn't get anything from phab until then?
That.
TASK DETAIL
https://phabricator.wikimedia.org/T763
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username.
To:
chasemp added a comment.
proposing removal of the auto cc of wikibugs-l until bugzilla migration is done
then
TASK DETAIL
https://phabricator.wikimedia.org/T763
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username.
To: chasemp
Cc:
mmodell added a comment.
ok I changed the rules a little:
Instead of adding the CC, new tasks simply send a single email to the list,
this will cut down on spam significantly.
**When all of these conditions are met:**
Projects do not include `security`, `operations`, `Human-Resources`,
Chad added a comment.
Maybe spammy isn't the right word, as it's not volume we're worried about. It's
that we're encouraging the filing of many tasks that aren't actually bugs or
enhancement requests in the software (broadly speaking). Tasks like team plan
for Q2 fall way outside the scope of
13 matches
Mail list logo
