Re: [Pulp-dev] Migrating Sprint to Custom Field [happening tomorrow]
[correction] I've left all values in the new custom field as active. When they are 'Archived' you could *not* query on them. They are all queryable now. On Thu, Mar 8, 2018 at 6:53 PM, Brian Bouterse wrote: > 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 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 >> 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 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 < ttere...@redhat.com> wrote: > Thank you! My late but big +1. > > Tanya > > On Tue, Mar 6, 2018 at 11:04 PM, Brian Bouterse > 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 >> 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://pu
Re: [Pulp-dev] Migrating Sprint to Custom Field [happening tomorrow]
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 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 > 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 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 < >>> ttere...@redhat.com> wrote: >>> Thank you! My late but big +1. Tanya On Tue, Mar 6, 2018 at 11:04 PM, Brian Bouterse 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 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@redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev >> >> >> >> ___ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >>
Re: [Pulp-dev] Migrating Sprint to Custom Field [happening tomorrow]
#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 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 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 > > wrote: >> >>> Thank you! My late but big +1. >>> >>> Tanya >>> >>> On Tue, Mar 6, 2018 at 11:04 PM, Brian Bouterse >>> 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 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@redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev > > > > ___ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> ___ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >> > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Migrating Sprint to Custom Field [happening tomorrow]
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 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 > wrote: > >> Thank you! My late but big +1. >> >> Tanya >> >> On Tue, Mar 6, 2018 at 11:04 PM, Brian Bouterse >> 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 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@redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> ___ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >> >> ___ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Migrating Sprint to Custom Field [happening tomorrow]
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 wrote: > Thank you! My late but big +1. > > Tanya > > On Tue, Mar 6, 2018 at 11:04 PM, Brian Bouterse > 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 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@redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >>> >>> ___ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >> >> ___ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> > > ___ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Migrating Sprint to Custom Field [happening tomorrow]
Thank you! My late but big +1. Tanya On Tue, Mar 6, 2018 at 11:04 PM, Brian Bouterse 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 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@redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev >> >> >> >> ___ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> > > ___ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Migrating Sprint to Custom Field [happening tomorrow]
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 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@redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev > > > > ___ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
