[Pulp-dev] Migrating Sprint to Custom Field [happening tomorrow]

[Brian Bouterse]

The porting of sprints to a custom field is done. Look for the 'Sprint'
field on all issues in Redmine which is queryable and assignable. Anyone
with admin access can add new values for this drop down field here:
https://pulp.plan.io/custom_fields/39/enumerations  I already added through
sprint 34. The new custom field has 'archive' option which I've set on
sprints <= 31. These are still queryable but archived values are not able
to be set on an issue which keeps the choice field short.

I've moved over all of the data so nothing was lost. I then deleted the old
milestones called 'Sprint 2', etc since they were no longer in use. They
did have historical date info, and so I saved that to a pdf in case anyone
wants to enter it into the wiki. I didn't think it was necessary so I'm
leaving it here.

I also updated the saved queries at the right to provide the same results
with the new fields.

Because of this now any plugin can make a roadmap using the milestone
feature of Redmine like the rpm plugin has: https://pulp.plan.io/versions/50

Send any questions/ideas/issues!

Thanks,
Brian


On Thu, Mar 8, 2018 at 12:36 PM, Robin Chan <rchan at redhat.com> wrote:

> #4 is done and here https://pulp.plan.io/projects/pulp/wiki/Sprint_Plans
>
> I'm going to revise my suggestion on sprint candidate. I think we can keep
> Sprint Candidate flag and set sprint = Sprint 34.
> And that will allow us to flag items for Sprint 35 (next sprint).
>
> Jeff - feel free to just make a decision here. I fear I may be over
> complicating things here. We just need a way to flag things by 3/22/18 dev
> freeze, lower priority "if we get time" items, and keep our ability to plan
> the next sprint.
>
> Robin
>
>
> On Thu, Mar 8, 2018 at 10:56 AM, Brian Bouterse <bbouters at redhat.com>
> wrote:
>
>> I'm porting these today. I'll handle items 1-3. If we really don't like
>> what it looks like we can revert.
>>
>> For item 4, I think we should make a wiki page with the sprint start/end
>> dates per sprint. I'll reply with links to the newly created things so
>> everyone can see it what we've got.
>>
>> On Wed, Mar 7, 2018 at 4:19 PM, Robin Chan <rchan at redhat.com> wrote:
>>
>>> A few impacts to sprint planning that I did not anticipate when reading
>>> this proposal (I was a +1 and late as well in putting that out there.)
>>> 1. We don't need to create Sprint 34 in preparation of Friday's sprint
>>> planning
>>> 2. Someone needs to create a Sprint 34 value in the new custom field
>>> 3. New Sprint 34 query need to filter by this new value.
>>> 4. Where do we record when our sprint starts or ends (in this case we're
>>> ending 3/22)
>>>
>>> -Robin
>>>
>>> On Wed, Mar 7, 2018 at 1:14 PM, Tatiana Tereshchenko <
>>> ttereshc at redhat.com> wrote:
>>>
>>>> Thank you! My late but big +1.
>>>>
>>>> Tanya
>>>>
>>>> On Tue, Mar 6, 2018 at 11:04 PM, Brian Bouterse <bbouters at redhat.com>
>>>> wrote:
>>>>
>>>>> Thanks for all the feedback! With many +1s and no -1s, I'm going to
>>>>> make this change tomorrow. I'll send out links to the result when it is
>>>>> done.
>>>>>
>>>>> -Brian
>>>>>
>>>>>
>>>>> On Mon, Mar 5, 2018 at 12:43 PM, Jeff Ortel <jortel at redhat.com> wrote:
>>>>>
>>>>>> +1
>>>>>>
>>>>>>
>>>>>> On 03/02/2018 04:17 PM, Brian Bouterse wrote:
>>>>>>
>>>>>> Redmine's milestone feature allows for roadmap pages to be published
>>>>>> for each project on pulp.plan.io like this one [0]. Currently all
>>>>>> projects use a single set of milestones from the main 'Pulp' project on
>>>>>> Redmine which is what defines the Sprints, e.g. 'Sprint 22'. This creates a
>>>>>> few problems:
>>>>>>
>>>>>> 1. Redmine projects can't use the milestone feature of Redmine for
>>>>>> release planning. This is unfortunate since the milestone feature is a good
>>>>>> release planning and roadmapping tool.
>>>>>>
>>>>>> 2. Any project that does use milestones can't have issues associated
>>>>>> with milestones also on a sprint. Like pulp_rpm pulp3 issues [0].
>>>>>>
>>>>>> I'm interested in hearing any solution on resolving these issues, but
>>>>>> I also have one to share:
>>>>>>
>>>>>> 1. We could create a custom field called 'Sprint' and make that
>>>>>> available to all projects.
>>>>>> 2. Populate the custom field with all existing Sprint values
>>>>>> 3. We then port the existing historic sprint issues to the correct
>>>>>> custom field which preserves all past sprints.
>>>>>> 4. Clear the milestone for all isues on plan.io
>>>>>> 5. Delete the old, unused milestones
>>>>>> 6. enjoy
>>>>>>
>>>>>> At least one issue at the upcoming sprint planning meeting won't be
>>>>>> able to be added because of this so I'm hoping we can resolve in the next
>>>>>> few days.
>>>>>>
>>>>>> [0]: https://pulp.plan.io/versions/50
>>>>>>
>>>>>> Thanks!
>>>>>> Brian
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pulp-dev mailing listPulp-dev at redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pulp-dev mailing list
>>>>>> Pulp-dev at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pulp-dev mailing list
>>>>> Pulp-dev at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Pulp-dev mailing list
>>>> Pulp-dev at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180308/846f8c65/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pulp_sprint_dates_pre_custom_field_switch.pdf
Type: application/pdf
Size: 29723 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180308/846f8c65/attachment.pdf>