On 02/15/2018 01:17 PM, Brian Exelbierd wrote:
== Changing metadata
Modify the table that drives
fedoraproject.org/easyfix that is located at
https://fedoraproject.org/wiki/Easyfix
The table would now include two additional columns (optional)
Col 1 = existing reference to the issue tracker. We should consider adding
gitlab.com
support
Col 2 = existing point of contact
Col 3 = category of task (documentation, infrastructure, programming-Haskell,
programming-Ruby, etc.)
Col 4 = SIG/WG/etc. this project is related too (Design, Council, KDE, etc.)
I like this page structure. I see it as more engaging to the people
reading the page too. Given some time to research it, I think this is
something that we could work on in CommOps.
== Changing
fedoraproject.org/easyfix
Today we show only two categories: Issues from Pagure/Github and Bugzillas
I believe those categories are not the right categories for consumers of the page. Using
the new category (col 3) above, we would break things out by the kind of contribution.
This would serve to let people browse related tasks more easily and to reduce the
overwhelming nature of the current lists.
+1.
= WCIDFF
WCDIFF should be extended to show the categories and groups appropriate for the various
endpoints. This way the person who navigates WCDIFF has the option of reading a specific
task they could work on right now, if they so desire.
I've wanted this functionality for a long time but needs dedicated
development time full-time. If not, then an active effort is needed to
create a roadmap with easyfixes rolled in to attract contributors.
In retrospect, all of this sounds like a good GSoC proposal. Not sure if
it's too late to expand on the idea and find a mentor for it.
= Marketing/Promotion
The categories give us the opportunity to promote our easyfixes as a great way to join or
contribute in a targeted manner.
+1. Super helpful for writing even outside of the Fedora community or
for anyone that wants to highlight a call to action to participate.
What do people think?
I'm interested in all the above, but skeptical to whether all pieces are
solvable by CommOps.
--
Cheers,
Justin W. Flory
jflory7(a)gmail.com