I got a bunch of ticket triage done today. I got us down to one row of tags
instead of 3. I also went through the !widgets list and got all of the
widgets on that list tagged widget. I did some other misc. cleanup
including cleaning up tickets that I knew were completed.
Just wanted to give a heads up because the ticket page looks a lot
different now. :)
Here's the meetbot minutes from the meeting we had today:
And here's the etherpad we started working on:
A short, quick summary of the high points:
- For Flock, we will prepare a *demo* (not a launch). (A proposed script for the demo is in the etherpad.)
- For our demo, we will focus on delivering a great experience for 3-4 hand-picked teams (right now, looking like design, translations, commops, and badges.) The widgets we work on will be prioritized based on what best serves those teams needs.
- We have different categories of work items:
1) the base fedora-hubs platform
2) the widgets (both user and team/project hub widgets)
3) non-hub Fedora infrastructure that needs to be modified to support things we want to do in hubs
- Pagure has a priorities feature that we will use. We'll use a flock tag to mark issues as needing to be resolved for flock, and the priority feature to mark priority within that set. Our issue set needs some triage / cleanup of extraneous tags etc (mizmo will do)
- devyani7 is going to focus on the bookmarks bar, which is the core navigational element in hubs and part of the platform.
- we're not sure what the other interns are going to work out yet, we'll need to meet again and keep fleshing out this plan.
(I think things will be clearer once we get the tickets cleaned up.)
New runserver script
- ryanlerch added a runserver script to run the dev server
We've got fedora-bootstrap!
- ryan lerch also splitted the templates, so that there is a master template that the hubs are using
- ryan lerch ported hubs to fedora-bootstrap
- fedora-bootstrap made things look quite pretty but broke a few things as well, like the ability to configure a widget, this has been restored today
Widget config/add/position work
- today, pingou has been adding the logic to add a widget
- so we should have all the bits and pieces in place to: add a widget, configure an existing widget, remove a widget
- hub wide, we have the logic to re-order them
- note: each widget now has a position argument, required, to determine if the widget should be only on the left column (for example feed), the right column (for example pagure's tickets) or present in both
- (both means it could go in either right or left column.)
- Dimuthu added the ability for widgets to have a footer. An example is the 'request a new meeting' button here https://pagure.io/fedora-hubs/issue/29#comment-599
ircb / waartaa
- on ircb, slick666 has been working on logging (he is one of the contributors to ircb)
- sayan and rtnpro are spending time on reading reactjs
- looks like reactjs vs angular
- not sure how to make decision - there is a thread on infra list: https://email@example.com...
- criteria: one that most people have experience with is most favorable, but it's harder because we dont have experience with them so much, so there's not a preferred one
- angular may be easier to learn
- rtnpro prefers react; details on the infra thread
- decision we'll have to make soon
apr 21 hack session with commops
- background - mizmo looking into badges ui for hubs eg http://pagure.io/fedora-hubs/issue/17
- big badges RFE for 'tracks' or groups of badges, would help bootstrap / on board contributors onto project/team hubs
- could have prerequisitie badge tracks
- decause, ryanlerch, sayan, flory7, mizmo met thursday night to talk about badges and hubs:
- layer 1: simplest implementation. no changes to badges. display badges related to a hub via tagging system already in place in hubs
- layer 2: simple badge track system. multiple badges together constitute a track. badges can have an order within the track or be orderless. ordered badge track might be something like, "make 1 blog post," "make 5 blog posts," "make 10 blog posts." orderless track might be something like, "participate in IRC meeting," "make 1 blog post," "post to team mailing list." Could also have combos of ordered and unordered badges within the same track.
- layer 3: badges sphere grid (example: http://glacoras.net16.net/Images/SSGOSG.gif) different colored areas represent different skill sets. in an RPG - black mage vs healer vs warrior. For Fedora badges, could be badge categories - content, development, testing, events, etc. Each node on the grid is a badge. And we could do things like this, to allow users to build out their skill sets, know what badges they need to earn to progress in a given category, even make recommendations for the next badges/task they might want to pursue or team/project hubs they might want to check out based on the badges they've earned. Could enable radar chart widget for user profiles so you can understand a given user's skillset: http://jsfiddle.net/fxs2n8s5/
- re layer 3: talked about this old mockup: https://fedoraproject.org/w/uploads/9/9a/FedoraRPG-mockup-startpage.png - here tracks are "missions," and when you complete a mission you get a "trophy." there is also a notion of "campaigns" where you can do x number of tasks to complete the campaign.
- problem with layers 2 & 3 is that it'd require a data model change in badges system, so when we make that change we should make it once for both to minimize impact.
- layer 1 is good enough for flock implementation.
- another idea from hyperkitty mockups: http://blog.linuxgrrl.com/wp-content/uploads/2013/08/user-profile.2.png
- concerns: too much like linkedin, worried about recruiters using data to contact users / harass
- we talked a bit about privacy measures, using fas +1 or shared group membership maybe as a requirement to view certain personal data on profile pages like the radar chart
- talked about making the radar chart against projects instead of skillsets
- talked about having a widget to list the projects someone's a member of
- talked about widgets like the mission progress widgets here: - talked about this old mockup: https://fedoraproject.org/w/uploads/9/9a/FedoraRPG-mockup-startpage.png
- goal with user profiles: serve as the FAS front end to user profiles, show how to best contact a person, help understand their skill set / if they are the right person to talk to about a particular project. no creepy, no stalker-y
- widgets can be configured by users, so they can always hide it if they are worried or add it if they want it
- we have a number of interns coming on, we should make up some milestones / goals for them so we can plan on what we'd like done in time for flock and help figure out tasks to work on to get towards it. will meet tomorrow at the same time.
- fedocal link for meeting: https://apps.fedoraproject.org/calendar/infrastructure/2016/4/27/#m3879 email mizmo if you want to be added to get a reminder
Good Morning everyone,
My name is Pierre-Yves Chibon (aka pingou in FAS and on IRC), I am a member of
the Fedora engineering team in Red Hat which gives me the opportunity to work
full time on Fedora and its community and even get paid for it, needless to say
I love my job :)
This is the same team that Ralph Bean was in, but he recently changed to another
team in Red Hat, this means that he will no longer have time to work on
I, however, will do my best to fill these big shoes :)
So see you all soon, in IRC or here and feel free to ping me if you have
I have this PR (that has been approved, but just not merged yet) that adds a runserver.py.
Just thought i would mention it here before I merged it, as it changes the way you run hubs when hacking on hubs locally.
previously, you ran python hubs/app.py to start your dev instance, now you run python runserver.py.
This was changed because I added a few arguments for specifying the port and host, and it made more sense to not have these command-line arguments in the app.py but have a seperate spript to start the dev server.
if there are not major concerns with this, i will merge!
Today, we put a brief and short planned period on the calendar for a
Fedora Badges Hack Session. In short, our target plans for tonight are
to touch on badge strategy with Fedora Hubs a little bit, and also
produce deliverables for some existing Badges tickets.
We'll likely try using Jitsi again for this, but if we have troubles, we
can move back to Google+. Please watch #fedora-commops for details on
the location as it comes closer to the time.
This is a late time for many in EMEA / APAC and we planned it last
minute, so it if it's a super late time for you, it's no problem if you
are unable to make it. Hopefully, soon we can try to find a more "ideal"
time for something like this in the coming future.
If you think you might be able to make it, please drop a reply on the
CommOps mailing list. Thanks!
Justin W. Flory
pingou and I talked about how adding a new widget will work at a user
interaction level in #fedora-hubs today. Here's a summary of the
- Meghan did some mockups for adding widgets to hubs. Her idea was that in
the upper right corner of the hub, if you are an admin, a button is
available that says "edit this hub." You click on it and you view the hub
in an edit mode, where all the widgets are in a config mode instead of
displaying their content, you can reorder the widgets, and there are
buttons to add new widgets. That is viewable here:
- pingou has already put some work into modal config dialogs, which are
available whe you click the 'edit' button in the upper right corner of
widgets. This pops up a modal that gives config options for that widget (if
you have admin access to the widget.) (You can see a mockup of one of these
here, but they look different right now and will for the first cut:
- We also talked about one of the design elements Meghan and I came up with
when making the mockups - that some widgets are right-hand column only, and
some are left. Whether or not a widget is one or the other depends on the
type and amount of info it has. The feed widget is the main left-hand side
one; there is also a 'welcome' / intro widget for hubs that has initial
rules / etc. that appears above the feed widget in many mockups. Most of
the widgets we have mocked up / have been working on are right-hand side
Okay with that upfront, here's the flow we talked about:
1) You want to add a widget to a hub. You're an admin.
2) Go to the hub.
3) Click on the 'new widget' button that appears in the column you want to
4) A modal dialog pops up. It has a dropdown list where you can pick the
hub you'd like to add. There is a "Next" button in the lower right, and a
"cancel" button to the immediate left of the button. You click next.
5) A second screen for the modal appears with the config fields you need to
fill out to get a widget of the type you selected created. Fill it out,
press "add widget" (this reuses the same code as the edit button on
individual preexisting widgets uses.)
6) You'll be brought back to the hub, this time with the new hub appearing
at the bottom of the stack. (might be nice to have subtle / slick animation
to show you where it ended up after you added it.)
7) Want to adjust the position of the new widget? Go to the upper right
corner of the hub and click "edit this hub." You'll enter 'edit mode' for
8) The contents of each widget fade to grey, and the name of each widget
fades in centered in the block of each widget. (The feeds widget just fades
out totally; it is not repositionable at this time.) The entire parent div
of the widget is a target for the click/drag action.
9) You can click and drag to reposition the widgets. You can move them up
or down within the column. They cannot be dragged between columns.
10) Once you're happy with your repositioning, you click 'save hub changes'
(a button that appears where the 'edit this hub' button was in the upper
right. The contents of the widgets fade back in as does the feed widget.
Some things we talked about to implement the drag and drop:
- jquery UI draggable/sortable
- sortable (https://rubaxa.github.io/Sortable/) this looks quite nice, no
Okay, hope that is a decent summary and makes sense! What do you think?
Here are the minutes from today's meeting!
- mizmo has been working on mockups for ticket widget (see
- the feeds widget was broken and pingou was looking at it (figured out a
fix after meeting.)
- sayan implemented an ident server (will allow a larger number of
connections) and logging in ircb (waartaa's bouncer) preparing it for 0.2
release with Flux architecture implmentation and is discussing with rtnpro
whether or not to usze React or Angular when they start working on waartaa
- we are moving the meeting time to 2 PM UTC Tuesdays
- decause noted GSoC student announcements will go out on 4/22