Re: [Wikitech-l] Difference between #goal and #epic
Disclaimer: this is a description of what I have used them, not an authoritative statement about how they should be used, nor a report on the norms for the entire userbase for this Phabricator instance. #epic identifies Phabricator tasks that comprise multiple other Phabricator tasks. They could be very large pieces of work, which have been decomposed into many tasks via Child Tasks. Or they could be 'tracking' tasks, holding a list of lots of other tasks, either through parentage or lists in the description or both. #goal identifies a Phabricator task that does not represent work to be done or a bug to be resolved, but instead is part of a project tracking system. So #epic is a fairly common project management tem used in Wikimedia Phab in its usual sense, and #goal has no set meaning other than what it means to the people involved in teaching that task. Joel Aufrecht (he/him, they/them) Program Manager (Technology) Wikimedia Foundation <https://wikimediafoundation.org/> On Tue, Jul 16, 2019 at 1:23 PM Martin Urbanec wrote: > Hello everyone, > > what is the exact difference between #goal and #epic on Phabricator? > > Thanks > > Martin / Urbanecm > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] Phabricator spam - account approval requirement enabled
Thank you Leon for this heroic effort, and thanks to everyone who helped in
this cleanup.
On Mon, Jul 2, 2018, 9:58 AM Leon Ziemba wrote:
> The bot has now completed it's run. If you see any outstanding tasks that
> need to be repaired, please give me the task IDs.
>
> The bot ran for roughly 36 hours, repairing at least 4,000 tasks (perhaps
> many more).
>
> There were some issues with the bot that may still affect your tasks:
> * The triage level was not restored, or was put in "Needs triage". This
> was fixed around 16:00 UTC on July 1. Hundreds of tasks were affected.
> * For most of the bot's run, it was subject to a newly imposed rate
> limiting. If the rate limit was hit in the middle of repairing a task, the
> bot may not have fixed everything. Many tasks were affected. This issue was
> fixed around 15:00 UTC on July 1.
> * For some tasks, the vandal removed tags as well adding some. The bot did
> not properly restore the removed tags until around 12:00 UTC on July 2. The
> number of tasks affected by this is estimated to be low.
> * Some tasks have "custom fields" that were vandalized, which the bot did
> not restore. An example is the "due date" on
> https://phabricator.wikimedia.org/T193593. The number of tasks affected
> by this should be very low.
>
> If you notice any tasks where the bot didn't fix everything, and you don't
> want to fix it yourself, just give me the task IDs and I can re-run the bot
> on those.
>
> Thanks to Andre, Mukunda, and everyone else to helped with this effort.
>
> ~Leon
>
> On Sun, Jul 1, 2018 at 8:49 PM Mukunda Modell
> wrote:
>
>> Hi Leon. I can't thank you enough for your efforts to help clean things
>> up in Phabricator. I can, however, help make the bot more effective. See
>> below for responses inline.
>>
>> On Sun, Jul 1, 2018 at 10:47 AM Leon Ziemba
>> wrote:
>>
>>> An update... the bot went to sleep as instructed a few hours after I
>>> went to sleep. Bot is now back up and running, with some ~4,500 tasks still
>>> to fix.
>>>
>>> A few problems:
>>> * The new "rate limiting" of the API is rather rigorous. Release
>>> engineering tried to whitelist the bot but we had no luck. So, it will take
>>> some time to go through everything.
>>>
>>
>> I'm still looking into why the bot hits the rate limit. I'm sure I can
>> come up with a way to get it whitelisted.
>>
>>
>>> * If the bot hits the rate limit while editing a task, all other changes
>>> it was going to make to that task didn't happen. Hence you may see only
>>> some corrections on some tasks.
>>> * The priority level is now being set to "Needs triage". This is because
>>> the Conduit API gives me numbers for the priority level, and the edit API
>>> wants a string (?!?). I don't know what numbers are for what priorities, so
>>> "Needs triage" it is. Older versions of the script left the priority level
>>> unchanged, so either way you may wish to review the priorities of your
>>> tasks. If you know what the priority number to string mapping is, please
>>> tell me :)
>>>
>>>
>> If you would like to alter the bot to restore the correct priority, this
>> should help; The priority levels are configured as follows:
>>
>> {
>> "10": {
>> "color": "sky",
>> "keywords": [
>> "lowest"
>> ],
>> "name": "Lowest",
>> "short": "Lowest"
>> },
>> "25": {
>> "color": "yellow",
>> "keywords": [
>> "low"
>> ],
>> "name": "Low",
>> "short": "Low"
>> },
>> "50": {
>> "color": "orange",
>> "keywords": [
>> "normal"
>> ],
>> "name": "Normal",
>> "short": "Normal"
>> },
>> "80": {
>> "color": "red",
>> "keywords": [
>> "high"
>> ],
>> "name": "High",
>> "short": "High"
>> },
>> "90": {
>> "color": "violet",
>> "keywords": [
>> "triage"
>> ],
>> "name": "Needs Triage",
>> "short": "Triage"
>> },
>> "100": {
>> "color": "pink",
>> "keywords": [
>> "unbreak"
>> ],
>> "name": "Unbreak Now!",
>> "short": "Unbreak!"
>> }
>> }
>>
>>
>>
>> Cheers,
>>>
>>> ~Leon
>>>
>>> On Sun, Jul 1, 2018 at 5:32 AM Max Semenik
>>> wrote:
>>>
We've got ourselves da MVP!
On Sun, Jul 1, 2018 at 12:51 AM, Leon Ziemba >>> >
wrote:
> I wrote a rollback script, currently running as CommunityTechBot
>
[Wikitech-l] Team Practices Coaching Clinic during 2017 Developer Summit
Team Practices Group Clinic TPG will be offering 15-minute consultations on team practices and collaboration topics of your choosing; for example: task tracking, improving communication between or within teams, or communicating with geographic diversity. See TPG_Clinic <https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/TPG_Clinic> to get more information. This is open to anyone attending the Summit. *-- Joel Aufrecht* Team Practices Group Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal to invest in Phabricator Calendar
As I understand it, https://phabricator.wikimedia.org/tag/phabricator-upstream/ is supposed to represent the complete, current list of WMF needs for Phabricator. So any discussion in this list should, in order to be re-usable in the future and fully transparent, be reflected in that list via, at least, making changes to tasks and citing this discussion in the comments. So, are there specific Phab upgrade needs, or upgrade needs that have been expressed but not captured in a Phab task? If so, could their owners please add them to the board? I have a few questions looking at that board that I'm happy to write up if someone can answer in this thread. Can the meaning of the columns be documented, e.g. here: https://phabricator.wikimedia.org/project/profile/6/ ? Looking at it, I have to wonder: - what is the difference is between Wikimedia Requests and Upstreamed? - If something has been Upstreamed, does that mean Phacility is going to work on it? Where would I go to learn the Phate of upstreamed requests? - How does something move from Backlog to Need Discussion to Ready to go to Upstreamed? - Are any of these lists prioritized? Thanks, Joel *-- Joel Aufrecht* Team Practices Group Wikimedia Foundation On Mon, May 16, 2016 at 9:46 AM, Rob Lanphier <ro...@wikimedia.org> wrote: > > If we're going to be investing money into improving Phabricator > upstream... > > It's really good that we're having a healthy debate about the > usability of Phabricator. I've enjoyed working with Phab a lot more > than the tools that it has replaced, but it is by no means perfect. > We have a role to play in helping Phab upstream make Phab more > perfect. > > That said, I think we should be careful with our assumptions about how > much influence we can buy with the money we have. We need to be smart > about how we spend it, but we also need to respect that we don't know > what our role is in upstream's priority setting and roadmap. We > shouldn't assume we're their most important customer. > > Without identifying specific issues, let's assume that we have a > feature list ordered like this: > * Feature A > * Feature B > * Feature C > - cut line for what we'd pay for > * Feature D > * Feature E > - cut line for features that we care about at all > * Feature F > * Feature G > > My (admittedly limited) understanding is that upstream is choosing > between Feature C and Feature G as the next big thing they work on. > If we chip in for Feature C, we could tip the balance and cause them > to choose Feature C over Feature G. > > I fear that a lot of the feedback seems to be "stop worrying about > Feature C; Feature A is *way* more important". If upstream is making > a C vs G decision, and we try distracting them with A, they may choose > to ignore us and opt for Feature G. There is a significant > opportunity cost in time and energy to spend influencing upstream to > pay attention to Feature A. > > Sogetting out of the abstract and into the specific: is improving > calendaring (T1035) important enough to invest a little money in, > *considered independently* of the other features we may want? Is it > above the "cut line for what we'd pay for" or is it less than that? > > Rob > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Raw notes from Wikimedia Developer Summit 2016
The index of notes for the Wikimedia Developer Summit 2016 <https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016> is located here: https://etherpad.wikimedia.org/p/WikiDev16-AllNotes. If you are aware of notes that aren't indexed here, please add them. Because Etherpad is not the preferred permanent medium for Wikimedia notes, please consider migrating your notes to mediawiki.org and linking them from the session calendar (first link). Thanks, *--Joel Aufrecht* Team Practices Group Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [editing-department] Read the VisualEditor process review
Hi Greg, The process improvement effort is not explicitly tied in with quarterly goals. If we come up with specific recommendations that require enough effort to register on a quarterly scale, or that influence the output of the team that much, they could be inputs to goal-setting. Team Practices Group also does the quarterly Team Health Check survey, which is also not part of quarterly goals. I think that process improvement in general is probably better handled separately from goals, to avoid creating any incentives to bias measurement stats, consciously or unconsciously. Joel *Joel Aufrecht* Team Practices Group Wikimedia Foundation On Sat, Jun 6, 2015 at 3:34 PM, Greg Grossmeier g...@wikimedia.org wrote: quote name=Neil P. Quinn date=2015-06-05 time=16:56:07 -0700 Hello everybody! For the past couple months, Joel Aufrecht and I have been working on a project to document and improve the VisualEditor team's processes; we just published a draft of our report https://www.mediawiki.org/wiki/VisualEditor/2015_Process_Review on mediawiki.org. If you're interested, please read it over and, of course, shout at us on the talk page if we wrote anything stupid. Neil et al, this is great! Thanks for the very informative read, even as someone who works closely with the VE team on a semi-daily basis (at least!). I think it is great that the time and energy was devoted to developing this report. The plan at [0] suggests that this is a one-time process with a conclusion (which is good), thus it isn't tied in, explicitly, with the quarterly goal planning process, correct? Best, Greg [0] https://www.mediawiki.org/wiki/VisualEditor/2015_Team_Process_Review#Plans -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
