3:33 p.m.
https://fedoraproject.org/wiki/Changes/fedora-change-wrangler
= Track Changes in Taiga =
The Motivation for this proposal is to propose using the Taiga
instance at teams.fedoraproject.org for Change processing.
[[User:Bcotton/UsePagureForChanges|Using Pagure]] was previously
proposed for this. The new Change Processing workflow aims to simplify
the process to improve visibility and ease of management.
== Summary ==
The current process allows contributors to propose changes in upcoming
Fedora releases. However, the management of those feature proposals is
cumbersome and requires several manual steps. This introduces more
opportunity for error and reduces the time available to the Change
Wrangler for more valuable contributions to Fedora. In particular, the
current process includes artifacts and discussion in the Fedora Wiki,
on mailing lists, FESCo tickets, Bugzilla tickets, and Docs tickets.
The current process is cumbersome with several manual steps,this
introduces more opportunity for error and reduces the time available
for the Change Wrangler.
A Cli Tool Written in Python that interacts with Taiga,Pagure and
Bugzilla.Functionality includes
Promoting,announcing,submitting,accepting and updating the changes
across the three platforms and over mailing list.
The new process will consolidate much of the information in
Taiga.Proposed Changes will be submitted as an issue in Taiga. The
description of the Issue will include the content with few exceptions:
* System-Wide or Self-Contained change will be indicated by a binary
in the issue metadata
* Fedora release will be indicated by a milestone in the issue metadata
* Change status will be indicated by a list selection in the issue metadata
== Owner ==
* Name: [[User:Pac23| Manas Mangaonkar]]
* Email: manasmangaonkar(a)gmail.com || pac23(a)fedoraproject.org
* Name: [[User:Bcotton | Ben Cotton]]
* Email: bcotton(a)redhat.com
== Detailed Description ==
As Part of GSoC 2019 the fedora-change-wrangler tool will be developed
to smooth out the workflow,reduce Manual Work involved for both the
Contributors and the Change-Wrangler(FPgm). The tool makes it easy by
covering all the functionality required for the process of moving
forward proposals.
The tool will be developed using Python 3.6+ and will interact with
Taiga/Pagure/Bugzilla via their API and the Mailing List via SMTP.
The General Workflow would be :
1. Change Owner opens an issue and fills in the fields. When they are
ready to submit the Change proposal, they set the status to "Ready
for Wrangler".
2. The Change Wrangler (FPgM) reviews the proposal. If it is
incomplete, they set the status back to "New" and inform the Change
Owner of what's needed. If it is ready to process, then...
Functionality covered
1. Promote
* The issue will be promoted to a user story in taiga,copies the
contents of the custom fields from the issue to the user story. Closes
the issue.
2. Announce
* The tool would have the functionality to enable announcing the
change proposal to devel and devel-announce lists using smtp. It will
also automatically change the story status to announced.
3. fesco-submit
* Allowing creation of a new issue in the FESco Pagure repo directly
from the command line.
4. Accept
* Once the changes are accepted the change-wrangler can create a
tracking bug in Bugzilla along with release notes on Pagure.THe status
of the user story is updated to accepted aswell.
5. Update
* Status can be changed to testable if BZ is "Modified" and to
Complete is BZ is "ON_QA"
6. Creation of Report
* The user can create a report to provide quick view of changes and
their status. It can be in wiki or Html form.
Techstack:
* Python3.6+
* SMTP
* Taiga/Pagure/Bugzilla API's
* Nano/Gedit/Vi ( Inbuilt support to edit text)
* Kerberos(For authentication)
The current sample arg created looks like this [ change-tool convert
--taiga <issue no> <issue no> ] . The advantage of this the Manager
would be able to specify unlimited no of issues to change at once in a
single command using the issue no in taiga to convert to user story.
== Benefit to Fedora ==
The proposed change will make the change-process easier for
everyone.Everyone would be able to see them in one place with
status,id filters. The current wiki process can be bit difficult for
formatting,having defined fields would mean easy access without the
cumbersome wiki edits.
Since changes would be submitted in Issue format on
Taiga,pre-submission discussions would be available thus getting
suggestions/feedback at the first stage itself would be easy for
everyone involved.
== Scope ==
* Proposal owners:
I will be working with the Change-Wrangler(Ben Cotton) throughout the
summer to create this tool from scratch.
* Other developers: N/A (not a System Wide Change)
* Release engineering:(no release engineering impact is expected)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
No visible Impact is expected.
== Dependencies ==
No other packages depend on this.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
Enough buffer time has been allocated to complete this during the GSoC period.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2:26 a.m.
I support this with every vote I have.
mkonecny
On 5/20/19 10:33 PM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/fedora-change-wrangler
= Track Changes in Taiga =
The Motivation for this proposal is to propose using the Taiga
instance at teams.fedoraproject.org for Change processing.
[[User:Bcotton/UsePagureForChanges|Using Pagure]] was previously
proposed for this. The new Change Processing workflow aims to simplify
the process to improve visibility and ease of management.
== Summary ==
The current process allows contributors to propose changes in upcoming
Fedora releases. However, the management of those feature proposals is
cumbersome and requires several manual steps. This introduces more
opportunity for error and reduces the time available to the Change
Wrangler for more valuable contributions to Fedora. In particular, the
current process includes artifacts and discussion in the Fedora Wiki,
on mailing lists, FESCo tickets, Bugzilla tickets, and Docs tickets.
The current process is cumbersome with several manual steps,this
introduces more opportunity for error and reduces the time available
for the Change Wrangler.
A Cli Tool Written in Python that interacts with Taiga,Pagure and
Bugzilla.Functionality includes
Promoting,announcing,submitting,accepting and updating the changes
across the three platforms and over mailing list.
The new process will consolidate much of the information in
Taiga.Proposed Changes will be submitted as an issue in Taiga. The
description of the Issue will include the content with few exceptions:
* System-Wide or Self-Contained change will be indicated by a binary
in the issue metadata
* Fedora release will be indicated by a milestone in the issue metadata
* Change status will be indicated by a list selection in the issue metadata
== Owner ==
* Name: [[User:Pac23| Manas Mangaonkar]]
* Email: manasmangaonkar(a)gmail.com || pac23(a)fedoraproject.org
* Name: [[User:Bcotton | Ben Cotton]]
* Email: bcotton(a)redhat.com
== Detailed Description ==
As Part of GSoC 2019 the fedora-change-wrangler tool will be developed
to smooth out the workflow,reduce Manual Work involved for both the
Contributors and the Change-Wrangler(FPgm). The tool makes it easy by
covering all the functionality required for the process of moving
forward proposals.
The tool will be developed using Python 3.6+ and will interact with
Taiga/Pagure/Bugzilla via their API and the Mailing List via SMTP.
The General Workflow would be :
1. Change Owner opens an issue and fills in the fields. When they are
ready to submit the Change proposal, they set the status to "Ready
for Wrangler".
2. The Change Wrangler (FPgM) reviews the proposal. If it is
incomplete, they set the status back to "New" and inform the Change
Owner of what's needed. If it is ready to process, then...
Functionality covered
1. Promote
* The issue will be promoted to a user story in taiga,copies the
contents of the custom fields from the issue to the user story. Closes
the issue.
2. Announce
* The tool would have the functionality to enable announcing the
change proposal to devel and devel-announce lists using smtp. It will
also automatically change the story status to announced.
3. fesco-submit
* Allowing creation of a new issue in the FESco Pagure repo directly
from the command line.
4. Accept
* Once the changes are accepted the change-wrangler can create a
tracking bug in Bugzilla along with release notes on Pagure.THe status
of the user story is updated to accepted aswell.
5. Update
* Status can be changed to testable if BZ is "Modified" and to
Complete is BZ is "ON_QA"
6. Creation of Report
* The user can create a report to provide quick view of changes and
their status. It can be in wiki or Html form.
Techstack:
* Python3.6+
* SMTP
* Taiga/Pagure/Bugzilla API's
* Nano/Gedit/Vi ( Inbuilt support to edit text)
* Kerberos(For authentication)
The current sample arg created looks like this [ change-tool convert
--taiga <issue no> <issue no> ] . The advantage of this the Manager
would be able to specify unlimited no of issues to change at once in a
single command using the issue no in taiga to convert to user story.
== Benefit to Fedora ==
The proposed change will make the change-process easier for
everyone.Everyone would be able to see them in one place with
status,id filters. The current wiki process can be bit difficult for
formatting,having defined fields would mean easy access without the
cumbersome wiki edits.
Since changes would be submitted in Issue format on
Taiga,pre-submission discussions would be available thus getting
suggestions/feedback at the first stage itself would be easy for
everyone involved.
== Scope ==
* Proposal owners:
I will be working with the Change-Wrangler(Ben Cotton) throughout the
summer to create this tool from scratch.
* Other developers: N/A (not a System Wide Change)
* Release engineering:(no release engineering impact is expected)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
No visible Impact is expected.
== Dependencies ==
No other packages depend on this.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
Enough buffer time has been allocated to complete this during the GSoC period.
2:46 a.m.
On 20/05/2019 21:33, Ben Cotton wrote:
= Track Changes in Taiga =
The Motivation for this proposal is to propose using the Taiga
instance at teams.fedoraproject.org for Change processing.
[[User:Bcotton/UsePagureForChanges|Using Pagure]] was previously
proposed for this. The new Change Processing workflow aims to simplify
the process to improve visibility and ease of management.
So I don't know much about taigi but I just had a quick browse
of a few things in that instance and I'm having some trouble
visualising what it would look like when used for this.
Is there an example page you can point at in the current instance
that gives some of idea of what a "change" might looked at when
documented in taiga? ie a view somewhat equivalent of the current
wiki page for a change that shows a one page summary of it?
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
2:57 a.m.
-1
I am against this proposal. For me as a contributor, Wiki works just
fine. It is readable, it is discoverable. It is tool which will
hopefully stand long after taiga is forgotten and the proposed script is
unmaitained.
Vít
Dne 20. 05. 19 v 22:33 Ben Cotton napsal(a):
https://fedoraproject.org/wiki/Changes/fedora-change-wrangler
= Track Changes in Taiga =
The Motivation for this proposal is to propose using the Taiga
instance at teams.fedoraproject.org for Change processing.
[[User:Bcotton/UsePagureForChanges|Using Pagure]] was previously
proposed for this. The new Change Processing workflow aims to simplify
the process to improve visibility and ease of management.
== Summary ==
The current process allows contributors to propose changes in upcoming
Fedora releases. However, the management of those feature proposals is
cumbersome and requires several manual steps. This introduces more
opportunity for error and reduces the time available to the Change
Wrangler for more valuable contributions to Fedora. In particular, the
current process includes artifacts and discussion in the Fedora Wiki,
on mailing lists, FESCo tickets, Bugzilla tickets, and Docs tickets.
The current process is cumbersome with several manual steps,this
introduces more opportunity for error and reduces the time available
for the Change Wrangler.
A Cli Tool Written in Python that interacts with Taiga,Pagure and
Bugzilla.Functionality includes
Promoting,announcing,submitting,accepting and updating the changes
across the three platforms and over mailing list.
The new process will consolidate much of the information in
Taiga.Proposed Changes will be submitted as an issue in Taiga. The
description of the Issue will include the content with few exceptions:
* System-Wide or Self-Contained change will be indicated by a binary
in the issue metadata
* Fedora release will be indicated by a milestone in the issue metadata
* Change status will be indicated by a list selection in the issue metadata
== Owner ==
* Name: [[User:Pac23| Manas Mangaonkar]]
* Email: manasmangaonkar(a)gmail.com || pac23(a)fedoraproject.org
* Name: [[User:Bcotton | Ben Cotton]]
* Email: bcotton(a)redhat.com
== Detailed Description ==
As Part of GSoC 2019 the fedora-change-wrangler tool will be developed
to smooth out the workflow,reduce Manual Work involved for both the
Contributors and the Change-Wrangler(FPgm). The tool makes it easy by
covering all the functionality required for the process of moving
forward proposals.
The tool will be developed using Python 3.6+ and will interact with
Taiga/Pagure/Bugzilla via their API and the Mailing List via SMTP.
The General Workflow would be :
1. Change Owner opens an issue and fills in the fields. When they are
ready to submit the Change proposal, they set the status to "Ready
for Wrangler".
2. The Change Wrangler (FPgM) reviews the proposal. If it is
incomplete, they set the status back to "New" and inform the Change
Owner of what's needed. If it is ready to process, then...
Functionality covered
1. Promote
* The issue will be promoted to a user story in taiga,copies the
contents of the custom fields from the issue to the user story. Closes
the issue.
2. Announce
* The tool would have the functionality to enable announcing the
change proposal to devel and devel-announce lists using smtp. It will
also automatically change the story status to announced.
3. fesco-submit
* Allowing creation of a new issue in the FESco Pagure repo directly
from the command line.
4. Accept
* Once the changes are accepted the change-wrangler can create a
tracking bug in Bugzilla along with release notes on Pagure.THe status
of the user story is updated to accepted aswell.
5. Update
* Status can be changed to testable if BZ is "Modified" and to
Complete is BZ is "ON_QA"
6. Creation of Report
* The user can create a report to provide quick view of changes and
their status. It can be in wiki or Html form.
Techstack:
* Python3.6+
* SMTP
* Taiga/Pagure/Bugzilla API's
* Nano/Gedit/Vi ( Inbuilt support to edit text)
* Kerberos(For authentication)
The current sample arg created looks like this [ change-tool convert
--taiga <issue no> <issue no> ] . The advantage of this the Manager
would be able to specify unlimited no of issues to change at once in a
single command using the issue no in taiga to convert to user story.
== Benefit to Fedora ==
The proposed change will make the change-process easier for
everyone.Everyone would be able to see them in one place with
status,id filters. The current wiki process can be bit difficult for
formatting,having defined fields would mean easy access without the
cumbersome wiki edits.
Since changes would be submitted in Issue format on
Taiga,pre-submission discussions would be available thus getting
suggestions/feedback at the first stage itself would be easy for
everyone involved.
== Scope ==
* Proposal owners:
I will be working with the Change-Wrangler(Ben Cotton) throughout the
summer to create this tool from scratch.
* Other developers: N/A (not a System Wide Change)
* Release engineering:(no release engineering impact is expected)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
No visible Impact is expected.
== Dependencies ==
No other packages depend on this.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
Enough buffer time has been allocated to complete this during the GSoC period.
3:51 a.m.
On Mon, May 20, 2019 at 04:33:57PM -0400, Ben Cotton wrote:
Please rename this to https://fedoraproject.org/wiki/Changes/TrackChangesInTaiga
The formatting of the page leaves a bit to be desired too, esp. the
"Detailed Description" section is mangled.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
Enough buffer time has been allocated to complete this during the GSoC period.
I think we need some contingency plan: if issues are filed for F32 in
taiga, and we decide do abort the switch, somebody will need to transfer
them back to wiki. This should be spelled out.
What is the long-term prospect? Our Change pages serve as documentation
even years after the fact (e.g. https://fedoraproject.org/wiki/Features/UsrMove
is being referenced in Debian as they do the same conversion…). Will taiga
be as long-lived? Are URLs in taiga stable? If we decide to switch away from
taiga, can we turn the Changes into static html or preserve them in some other
way?
Zbyszek
11:51 a.m.
On Tue, May 21, 2019 at 4:52 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
The formatting of the page leaves a bit to be desired too, esp. the
"Detailed Description" section is mangled.
I've cleaned up the formatting there a bit.
> == Contingency Plan ==
> * Contingency mechanism: (What to do? Who will do it?) N/A (not a
> System Wide Change)
>
> Enough buffer time has been allocated to complete this during the GSoC period.
I think we need some contingency plan: if issues are filed for F32 in
taiga, and we decide do abort the switch, somebody will need to transfer
them back to wiki. This should be spelled out.
I added a note that I will convert existing changes to wiki pages if
necessary (and churchyard brought up in IRC that he already has an F32
proposal accepted. I will move that to Taiga for him, as well as any
other F32 proposals that come up as this is being implemented).
What is the long-term prospect? Our Change pages serve as
documentation
even years after the fact (e.g. https://fedoraproject.org/wiki/Features/UsrMove
is being referenced in Debian as they do the same conversion…). Will taiga
be as long-lived? Are URLs in taiga stable? If we decide to switch away from
taiga, can we turn the Changes into static html or preserve them in some other
way?
I can't say if Taiga will out live the wiki. I can say that it is an
area of importance for the Council and the Community Platform
Engineering team.
Taiga's URLs are stable, in my experience.
We can preserve the content if we decide to switch away at some point.
There's a part of me that thinks change descriptions should be
committed to a docs repo after implementation (as an appendix to the
release notes, perhaps), but that's outside the scope of this
proposal.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
3:13 p.m.
To address some additional questions and comments that have come up:
The discoverability with this process is still good. We'll still
produce either the wiki ChangeSet page or a static HTML page that
contains similar information. Both options would still allow for
search engines to get the content. In some ways, discoverability is
improved because a page can't be "lost" by mistyping a category.
There is an example change available for view:
https://teams.fedoraproject.org/project/bcotton-test-changes-tracker/us/1...
The idea is to separate things that are more like metadata from the
content of the change itself. This allows for easier reporting and
removes the need for change submitters to try to get free-form content
into a parseable form.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2:23 p.m.
On Mon, May 20, 2019 at 4:33 PM Ben Cotton <bcotton(a)redhat.com> wrote:
After working to implement this proposal over the summer, we have
discovered two issues with the Taiga UI that make this proposal more
annoying to community contributors than I'm willing to accept.
The first is that each custom field requires a distinct click on the
field's save button. Since the workflow makes heavy use of custom
fields, this is annoying and could result in losing data. This is
filed upstream: https://github.com/taigaio/taiga-front/issues/1029
The second is that custom fields are not available when creating
issues. You have to create the issue and then edit it to set the
custom fields. This is less bad, since most wiki-based change
proposals are edited multiple times anyway, but along with the
previous issue adds an extra level of annoyance. This is filed
upstream: https://github.com/taigaio/taiga-front/issues/608
Both of these issues are avoided by submitting issues via the API.
Manas (pac23), who spent this summer working on tooling for this
proposal, included this functionality in the tool. However, I don't
expect that all contributors will use the tool to submit change
proposals. The current state of the web UI is sufficient to make this
more annoying than I want the process to be.
I still like the principles behind this proposal, and if the upstream
issues are fixed (or if another suitable platform comes along), I will
revisit it. In the meantime, we'll continue using the current wiki
workflow.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1684
days inactive
1796
days old
7 comments
5 participants
participants (5)
-
Ben Cotton -
Michal Konecny -
Tom Hughes -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek