On Fri, Aug 24, 2018, 11:38 David Sommerseth <dazo@xxxxxxxxxxxx> wrote:
On 23/08/18 22:43, Ben Cotton wrote:
> Hi community,
>
> We've traditionally used the wiki for Change proposals because it's
> the tool we had. But, it's not necessarily well-suited to the purpose.
> But now we have Pagure, which can help address some of the
> shortcomings of using the wiki: poor scriptability, no reporting, and
> a lot of copy/paste.
>
> So I've come up with a plan that would use Pagure instead:
> https://fedoraproject.org/wiki/User:Bcotton/UsePagureForChanges
>
> You can read the full details on the wiki page above, but the general
> idea is that we won't change the policy for Changes, just how we store
> and manipulate them. My intent is to make it nearly seamless for the
> community while giving us a platform for building on the process in
> the future. Note that this would run parallel to Bugzilla for a
> release or two and then replace Bugzilla for Changes tracking.
Even though I'm not as active here as I would like to be, I generally like
this idea.
A few things which would be good to sort out are:
* Still requires changes be represented in three different Pagure repos
* We lose edit history if a change proposal is updated based on feedback
Well, I suppose Changes could be represented as markdown/reStructuredText files in a repository instead of issues on pagure? Then edit history is no problem (that's what git is for), and proposed changes can be done via pull requests.
Off the top of my head I'd suggest using a "fedora-changes" (?) project on pagure with folders for different fedora releases.
- Edit history is accessible through git
- Changes can be submitted and updated with pull requests
- Postponing a change is as simple as moving a text file from one folder to another
- Rejected or discarded changes can be archived in another folder
(Just thinking out loud here.)
Fabio
>From my point of view, those are the most critical ones. The history is good
when you want to see if/how things changed - to learn from specific changes
which went well or really bad. Not having a history to base it on makes this
learning somewhat more difficult - as you don't know exactly how a change
proposal did develop, just the final result.
Also having changes represented in three different repos sounds a bit too
bureaucratic to me. Processes are good to have, but in the moment they get
too complicated people will generally try to avoid them. If it is really
needed to involve three repos, then a decent tooling on top of it is needed at
launch time; to hide this bureaucratic process a bit.
Other than that, I think this idea makes perfect sense. The first time I did
a change proposal (not even system-wide), it felt like an odd process ("Is
this the right template? In a wiki? Have I filled out all the proper fields
correctly? How is this proposal picked up and distributed properly?" are some
of the thousands questions which popped up).
--
kind regards,
David Sommerseth
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/JS64TGXC3LBM4XZY2HOSFWL4BHJ5QSYO/
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/R5H22KIXOWYIKUYIRSXZVOZNHINOBVLC/
