#239 Proposal for Fedora Badges Hackfest 2019
Closed: approved 5 years ago by bcotton. Opened 5 years ago by jflory7.

Summary

Hold a Fedora Badges FAD / hackfest in early 2019 to focus on a more sustainable future of Fedora Badges

Background

See the full proposal on the wiki.

A logic model is duplicated here for simplicity:

Fedora Badges Hackfest Logic Model - v2.png

Details

The estimated budget is approximately $7000 USD (more detailed cost breakdown in the wiki). Participants include myself, @riecatnor, @nb, @sayanchowdhury, @tanvi, and @kylerconway.

We also hope one Fedora Council member will be able to attend, possibly @bex or @mattdm. Additionally, some folks may be able to participate part-time in the FAD from the Czech Republic / Brno (@mleonova, @churchyard).

Outcome

From wiki:

  • Mission: Chart a sustainable future for Fedora Badges.
  • Vision: Implement short and long term strategies to keep Fedora Badges relevant and a useful tool to the Fedora Project as a whole.

Because of the proposed January 21st – 23rd 2019 dates, reviewing the proposal before the holidays start helps us plan effectively.

About https://meetbot.fedoraproject.org/fedora-meeting-1/2019-01-02/council.2019-01-02-15.00.log.html

Main technical issues IMHO:

  • current new badge deployment sucks but there is no dev to have time to make it any better
  • new badge ideas are blocked (or are supplemented by manually awarded badges) on nobody knowing how to technically create them (e.g. the "I voted" badge should really be awarded automatically, not manually)
  • badges usually get ready on the artwork side and then sit there forever to get a rules.yaml file (unless it's a copy-paste-edit badge) because nobody involved is capable of creating new rules or has free cycles to do so
  • conclusion: we only have new manually awarded badges for years. we rarely have any automated badges that can provide some contributions metrics, when we do, it's a copy paste of an older badge (e.g. Copr 999 builds was copied and edited from Copr 300 builds)
  • example of the frustration: the Pagure badges are broken since they were deployed in 2016

@churchyard I don't think any of those sound like technical issues. They sound like lack of developer time issues. That's fundamentally the problem we're worried about. We want the project set up to succeed, and if these are the blockers, while the FAD mainly focuses on work above these problems, that seems... concerning.

Not really relevant to the decision, but : I know all the docs aren't updated, but I'd really like to move away from the overly-jargony term "FAD" for these kind of multi-day events. Let's call them "hackfests".

The term "Fedora Activity Day" should be used for its original meaning: single-day Fedora events usually attached to other conferences.

That's actually what I had in mind: issues you've been worried about in the meeting. Sory for calling them "technical issues".

One thing is that it's not only lack of developer time, it's mostly lack of developers who would work on badges at all.

.> One thing is that it's not only lack of developer time, it's mostly lack of developers who would work on badges at all.

I think this is very true and generally a problem with quite a few apps developed and maintained by Fedora Infra. We mostly have legacy applications in the case of tahrir (badges) most of the commits happened in 2013-2014 then it has been in maintenance mode. Also the technology stack used (Pyramid, Mako templates and JQuery) is not very appealing to for developer looking to get more experience or add some shiny open source project to their CV.

Not sure what is the solution to this maybe doing a code bounty program to motivate people to work on the issues.

We discussed this ticket in the council meeting yesterday and offline as well. We would like a bit of a stronger focus on one of the aspects of the proposal.

Under the heading of "More manageable workflow" the council feels that one of the major hurdles of the workflow is lack of technical automation and (new) developer experience. As a result, we would like to propose some modifications of your proposal.

1) In the second of the Primary Goals "New documentation for on-boarding to both design and development" the description really focuses on documenting user experience. However, the council feels documentation and creation of a simple to use developer experience would help with contributions. For example, providing a container or vagrant image configured for development and test with documentation would be a good outcome of this FAD.

2) In the 3rd Goal "Outreachy intern to work on Fedora Badges stack" you plan to deliver a "plan for mentors." The council feels you should go one step further and actually identify one or more mentors for one or more interns. With this outcome, intern proposals could be directly generated.

Thanks to all for the reviews. Justin and I worked up this proposal, and with your feedback, would like to re-propose with more direction. We are working on prioritizing a list of technical needs/goals/ideas and refining some of the other facets of the proposal. We hope to have a revised version ready for further feedback by January, 28th.

looking forward to it @riecatnor thank you for doing this.

All: the wiki/logic model/proposal has been updated based on feedback. Please review and let us know your thoughts. We are looking for feedback on the changes/proposed dates before we finalize the budget. Thanks!

https://fedoraproject.org/wiki/Badges_Hackfest_2019?rd=FAD_Badges_2019

+1 to the updated proposal. I'd like to see more about how the plans that come from the Hackfest will be executed, but there's only so much that can be known ahead of time.

Is everyone listed as inputs actively supporting this proposal? Are they planning to contribute significantly for a longer period after the hackfest?

Based on the plan as written at https://fedoraproject.org/wiki/Badges_Hackfest_2019?rd=FAD_Badges_2019 I am -1

  • Only two of the identified developer people have confirmed participation
  • Technical issues on the system that are being raised today are languishing without response leading me to believe that the developers aren't familiar with the current system or don't have time to actually work on this project
  • we have no identified mentor for the outreachy
  • We may get help from CPE/Infra later this year and the timing is wrong to take advantage of that.

Hi @bex:

Technical issues on the system that are being raised today are languishing without response leading me to believe that the developers aren't familiar with the current system or don't have time to actually work on this project

Could you give context on the technical issues you are seeing? The back-end was migrated to Python 3 this month. I want to better understand your perspective on this feedback.

we have no identified mentor for the outreachy

@sayanchowdhury volunteered to mentor but I have not updated this in the wiki proposal yet.

We may get help from CPE/Infra later this year and the timing is wrong to take advantage of that.

Perhaps focusing on technical / software challenges for this hackfest is not the best use of this event's time. But the feedback does not address design needs and challenges explained in the proposal. Five of the seven identified goals focus on design. Most participants are designers.

I feel stuck on this proposal. The initial feedback we received was there was not enough emphasis on the software stack. The feedback I am reading now is there are unanswerable questions today about the software stack that blocks this hackfest.

How do you propose we move forward?

@lgriffin has asked for a spec for the badges app similar to the one for Rawhide gating. Bex, would having a document like that come out of the FAD address your concerns?

In today's Council meeting we agreed that the clock is started for voting on this ticket, so we will have a final vote tally on this in 7 days.

Well, we have lot of +1s already. @bex are you -1 right now?

We have 1 +1 to the updated proposal. We can count the previous +1s, but given the discussion over the last two months, I didn't want to assume people who were previously +1 still are.

Okay, so, here's the line. Votes below the line. :)


I'm +1 to this as it stands.

I am -1 at least as long as my questions are not answered.

Hi @bex:

Technical issues on the system that are being raised today are languishing without response leading me to believe that the developers aren't familiar with the current system or don't have time to actually work on this project

Could you give context on the technical issues you are seeing? The back-end was migrated to Python 3 this month. I want to better understand your perspective on this feedback.

I am looking at response to non-awarded badge tickets and troubleshooting methodologies. Migrating a code base from python2->python3 is important, but I am concerned we migrated a buggy code base and don't have a plan to actually make it work, we just made it compile.

we have no identified mentor for the outreachy

@sayanchowdhury volunteered to mentor but I have not updated this in the wiki proposal yet.

This is good news. It'd be great to see that commitment documented. My reaction has been to the proposal as it stood at the time of my comment.

We may get help from CPE/Infra later this year and the timing is wrong to take advantage of that.

Perhaps focusing on technical / software challenges for this hackfest is not the best use of this event's time. But the feedback does not address design needs and challenges explained in the proposal. Five of the seven identified goals focus on design. Most participants are designers.
I feel stuck on this proposal. The initial feedback we received was there was not enough emphasis on the software stack. The feedback I am reading now is there are unanswerable questions today about the software stack that blocks this hackfest.

i greatly appreciate the policy and design issues that want to discussed and worked on in this hackfest. However, Badges is a "three-legged stool" of design, policy, and technology. No two legs alone are sufficent. If we just fix policy and design but don't actually fix our tech stack to enable the features we need to be successful, I don't feel like we have accomplished much. 3.5 of the 5 Primary objectives have direct technology dependencies. This is why I feel like these technology questions are blockers and not just annoyances.

I have not seen strong technical commitment in this project. I am hearing that Red Hat may have some resources to provide this project later this year. Until those materialize, I am worried this hackfest will not result in a much of output that required an in-person meeting.

I don't want to see us use badges as an onboarding project for new contributors who find out their work is blocked on technical issues so the badge never gets deployed or once deployed is never awarded.

For these reasons, I remain -1 to the proposal today. This is not a forever problem, but forcing this hackfest today forces me to vote today.

I am honestly not sure how to grow the technology commitment on this project. This is very concerning to me in multiple areas, and I personally haven't figured out an answer yet. I don't want this hackfest to become stuck on a long debate about contributor attraction, but this hackfest is endangered by this problem.

Taking this a bit further I view hackfests as places where we jump start projects or where we try to move the project forward rapidly in a short time. This second case, is usually proceeded by a period of regular contribution that over time identifies the stuck bits that are able to be moved forward in this manner. This is a mature project that is basically void in a specific contributor area. The lack of an ability to even scope the problems in advance of the hackfest means that we can't even know that the people who show up can learn the code base and get code written to solve the problems. If they can't, in an environment of no regular contribution, we have set up the project to have, at best, half-done work and a theoretical plan to finish, that a new set of contributors will have to analyze and learn in the next hackfest. That doesn't seem like a recipe for success.

I also don't see a desire on the part of the Fedora community to move our project to one where we do our work in a sequence of cadence-planned hackfests and minimal to no work is done between. This seems to be the pattern this project is aiming at. This is not necessarily a negative pattern, however, I don't think it is one we are prepared to resource over time.

Hi, Marie and I both met today to review this feedback. We both wrote replies but thought it was helpful to post them both individually:

Thank you all for the feedback. I have a few thoughts I would like to share.

Aside from the development aspect of Badges, I believe that providing the space, time and resources for contributor based designers is invaluable. The time I am able to provide to the project is used to maintain the design aspect project, mostly on my own at this point in time. We have a couple design contributors on the list who are newer to the project, and I would love to bring them further into the fold, energize them, teach them in person about the design goals of this project.

To really further this project from the design side, we need a concentrated push. I feel I do not need to tout the benefits of bringing people together in the same space and how productive that can be. In my opinion, a hackfest that is ~only~ focused on the design aspect of the project would still be valid, important, and worth the funding.

Unfortunately, I have a lesser understanding of what needs to be done on the technical side, but I have recognized the lack of contributions and development of this aspect (which I have spoke up about as early as Flock in Cape Cod). I am here to support that side of the team with my perspective as the design maintainer, and vocalize what I think would be an ideal output, but I am less able to say “ok, this is exactly what needs to be done”. What I can also do is work to improve the design, the workflow, the policies, to make those the best they can be, as well as support and mentor an intern on the UI/UX.

I am more than willing to continue to commit my time, my passion, and energy to this project, as I have for the past 5 years. That, as well as jflory’s energy is where the drive to make this event happen came from. Although I am hearing the concerns, this reaction furthers the point that I made at Flock this past year: that the value put on design in Fedora is lower than development and honestly it is quite disheartening. I think this is a great chance to prove that is not the case. There is more than enough work for the badges design team to fill 3 days of work and then some, and there is no doubt in my mind that this event would be have direct and tangible improvements to the design of Fedora Badges and the project as a whole.

@till said…
Is everyone listed as inputs actively supporting this proposal? Are they planning to contribute significantly for a longer period after the hackfest?

Everyone but two of the people listed underneath inputs are actively supporting the proposal. Máirín will likely be unavailable during the suggested dates. Clement is not able to participate directly but was interested in contributing remotely.

All other listed participants have a demonstrated record of contributing to Fedora Badges as volunteers and one as a paid employee of Red Hat. Could you clarify what you envision as significant long-term contributions to Fedora Badges? There is a demonstrated pattern of long-term engagement with Fedora Badges but the cadence is slower since most of the community is non-funded volunteers.

@bex said…
[snip]

What is the Fedora Project’s commitment to the Fedora Badges application?

Earlier, you said the design, technology, and policy are weighted equally; however, the feedback given speaks to me that the technology is the only valuable component and all other components are secondary.

If there is a possibility of future paid development work on the Fedora Badges stack in the future, this is an excellent possibility. But I do not see design work and prioritization of existing development work as blocked by this possibility. While design and tech are related, the identified design goals are independent of development work. For example, one of the needs is to revisit the existing design resources created in 2014. Some work is needed to modernize the design guidelines based on new categories of badges created since the resources were created. This work enables the design component of Fedora Badges to improve and scale for changes over the last four, almost five, years. If future development crystallizes, I do not see the design goals as blocking or interrupting future development work. Specific examples of how you feel future development is a hard blocker to design is helpful to understand. Could you elaborate on this point?

To the comment of cadence of hackfests and where work is done, most of the goals identified for this hackfest are design goals. There is a demonstrated pattern of long-term activity to the Fedora Badges application in the design contribution area. The comment of cadence-planned hackfests where no work is done in-between says to me that the design work is not valuable to the Fedora Project, because there is a demonstrated record of long-term work, by unpaid volunteers, for over five years since the project’s inception. There has also never been a Fedora Badges FAD / hackfest in the history of the project. For development, I understand there are concerns about long-term development after the hackfest, but I believe getting existing stakeholders in the same room together enables us to think about how development goals are planned and prioritized for Fedora Badges. That work is not happening now. Spending time to address project management techniques for Fedora Badges helps us build a sustainable roadmap for long-term development, even if the pace of development is not a rapid or fast-moving speed.

Since there is some paid development time allocated to Fedora Badges, addressing project management is important. One of the issues we are struggling with is the prioritization of work. I feel we are not taking full advantage of the development time that is already allocated to Fedora Badges. The hackfest enables us to better leverage our existing resources by sitting together in the same room to map out these tasks and goals for at maximum a year out (in case future resources from Red Hat Community Platform Engineering do crystallize).

Ultimately, I think this response requires an answer to the question of what Fedora’s commitment to the Fedora Badges application is. From the response, the design component of this event does not feel valued in comparison to the technical work. I believe the two are not fully co-dependent on each other and this event can still be successful even with existing questions about long-term development of Fedora Badges. This is why I want to know what Fedora’s commitment is to Fedora Badges; if there is not a commitment, this hackfest proposal does not make sense and I agree it should not happen. If Fedora is committed to Fedora Badges, I still identify a strong need and value of this hackfest proceeding with existing goals and milestones.

The addition of interested parties who will commit to the engineering portions of this proposal allow me to be in favor of this. I withdraw my -1. I will be traveling next week and unable to provide significant assistance, so please work with me asap to help with this assuming it is approved.

@riecatnor
We have a couple design contributors on the list who are newer to the project, and I would love to bring them further into the fold, energize them, teach them in person about the design goals of this project.

This is great to know and something that makes the hackfest more interesting from my point of view. Is it a problem that Máirín is not able to attend for this?

As a side note I have started a wiki page to help gather technical requirements and I trying to organize a vFAD next week to get people together to brainstorm user stories so we can start building a backlog.

@jflory7
All other listed participants have a demonstrated record of contributing to Fedora Badges as volunteers and one as a paid employee of Red Hat. Could you clarify what you envision as significant long-term contributions to Fedora Badges? There is a demonstrated pattern of long-term engagement with Fedora Badges but the cadence is slower since most of the community is non-funded volunteers.

I would like to understand what kind of future contributions are planned after the hackfest. Since you are highlighting that one of the developers is a paid Red Hat employee. Does this matter for this proposal? Will he spend a significant time on the badges app in the future? Why is he not writing this for himself? As far as I know, most of the developers are already engaged in a lot of areas in Fedora. Therefore it would be far more convincing if this hackfest could onboard new, diverse contributors. If some of the old contributors are planning to shift their focus to spend more work on Badges, it would be more convincing as well.

I will assume that you wanted to imply by talking about the past contributions that there are going to be future contributions from the listed developers after the hackfest. I withdraw my -1 as well.

Based on the votes and the lack of further objection in today's Council meeting, this proposal is approved.

Metadata Update from @bcotton:
- Issue close_status updated to: approved
- Issue status updated to: Closed (was: Open)

5 years ago

Login to comment on this ticket.

Metadata
Attachments 1