We had a weekly status meeting today. Here are the meetbot minutes:
Here's a summary:
- jcline has a PR open against FAS3 (https://github.com/fedora-infra/fas/pull/255) to add the necessary IRC fields. he will ping today to see if it can be reviewed soon.
- jcline explored how widgets work in hubs and wrote up his findings as documentation in https://pagure.io/fedora-hubs/pull-request/302
- jcline spent time implementing the db change in hubs and then changing his mind
- abompard and jcline talked about modules vs classes for widgets and agreed classes would be better. classes are a bit more work because it requires defining an interface, but classes are more flexible and can be implemented anywhere that is python-accessible and allow us to provide default implementations thru inheritance.
- abompard has some widget-related stuff written, jcline will review abompard's open PRs today to unblock him
- jcline got the API autodocs going for Hubs, I just haven't made a PR yet because it depends on my first docs PR
- nothing back from openstack so we're going to assume we're on our own wrt meeting bots
- abompard thinks he can implement a change in the hubs config that will give him the necessary info to implement the widget without needing to change meetbot. hubs users would need to list the channels they are working on, this info would be used by the halp widget to filter the halp requests but it could be used by other widgets too. that's why I think it's more a hub-level config (I'm thinking of the IRC widget, but maybe also a meetings widget, etc)
- We talked about it being nice if it was shared - e.g., it would be nice to have notifications of the data go to the stream as well as the halp widget.
- the main use case for the halp widget is the comm ops folks altho other people could use it too. the comm ops folks aren't necessarily members of the teams that are looking for help but they try to identify which teams need help at a higher level and route helpers as needed.
- (1) If a given user doesn't have IRC activated, they still would be interested in halp requests that have to do with teams they are a member of (2) we may at some point want to make it possible to monitor other info (beyond IRC) to create halp items in the widget. (3) we may at some point want to make it possible to manually enter in a halp request to the halp widget
- For (1) abompard needs a list of IRC chans used for each hub, and (2) and (3) don't change the decision. He will just make sure the table can hold more info than just a list of IRC chans
- we talked about http://blog.linuxgrrl.com/2016/11/15/fedora-hubs-and-meetbot-a-recursive-... and how some teams meet in #fedora-meeting-* channels and how some meet in a team channel. That is still a complication but doesn't block this implementation plan. Simple idea for getting team minutes out of #fedora-meeting-* channels - use the meeting name from meetbot: each hub's admin could have a configuration for the hub that they could add their meetbot meetingname tags to, then you wouldn't have to upgrade meetbot
Regional Hubs UX
- shillman setting up times to have people try to use prototypes. she had her first sessions with a2batic last night
- shillman touching up the social media/photo sharing survey. It's meant to try to get an idea of what sorts of social media/photo sharing tools people are using, with the intent to have some conversation between Hubs and those tools available.
- blogged html/css convo part one, need to continue part 2 since we got mired in python & JSON details and didn't get to html/css so much: https://medium.com/@suzannehillman/css-and-mockups-2bf6fb160fa2#.tlw423lrt
I'm wondering what the difference is between the "live feed" on a hub's front page and the "My Stream" page (which is not deployed on hubs-dev).
Both pages seem to share a lot of the structure, and maybe I'll do some refactoring, but first I'd like to understand what are the differences.
Suzanne and I had a quick meeting today to discuss her work on regional hubs. Topics covered:
- Format of feedback I'm giving her on her mockups
- Social media research she has been doing to see what platforms Fedorans are using to share information / photos / reports about Fedora events
- Prototype testing plan for her mockups thus far
What we decided:
- I'm going to make smaller mockup feedback files
- Suzanne will update mockups based on feedback and to prep them for prototype testing
- Current social media research is based on consultations with previous hand-picked regional interviewees; for more aggregate data Suzanne will put together a Fedora-wide survey
- Suzanne will prep for prototype testing by coming up with tasks for the tests
Today we concluded our meeting by deciding to meet again tomorrow from
1500 - 1600 UTC (with ahard stop at 1600 UTC):
- Thursday Jan 12
- 1500-1600 UTC (10-11 AM EST)
Here's a summary of what we discussed today with a link at the bottom to
Target Audience / Milestone Goal Discussion
- We'll focus just on the design team for our milestone 1.
- This means the main development focus will be on IRC.
- Rationale for this decision includes:
(1) the main external dependency to design's hub is waartaa, which
sayan is upstream for
(2) getting an initial cut of IRC benefits all hubs; zanatasupport,
while critical, isn't as widely applicable
- we are leaving the current milestone tag aloneas a tag to be used for
any tickets that relate to our 3 key target audiences; we are creating a
new milestone tag "milestone1" for our first milestone:
- ACTION NEEDED: taggingIRC tickets and other essential tickets with
IRCFeature Deep Dive Discussion
We came up with a list of atomic tasks that need to be done in the
codebase to get IRC implementedto get the IRC widget working. This was
all in the context of getting the IRC widget ticket completed:
1) add setting of whether or not IRC is enabled to the User database
model and switch it on and off via the UI
2) add switch in UI to turn off a given channel in the irc widget so
users aren't idling in it if they dont want to
3) upon clicking on button to enable IRC feature, log user on
4) for users who do not have an IRC nick configed in FAS, we need to
direct them to set one up
5) mock up tool for helping new users set up their freenode nick and
register it. should save out to FAS afterwards
6) figure out how to handle when user doesn't confirm email acct with
freenode after 24 hrs of nick reg (reference:
7) (some future point) add a config option to allow for the user to
connect to a proxy they control rather than thru ircb (eg if they have
some external log store they want to make sure their logs save out to)
Note the narrative for this feature here - IRC is very integrated with
Hubs. Some points:
- By default, IRC is not enabled for a given user in hubs. Any IRC
widgets on hubs will be greyed out and have a little promo to encourage
the user to opt-in with a widget / button / switch for them to enable
it. This should also have the caveat they should be logged out of any
proxies / etc before they do it (otherwise we'll knock their proxy out.
- FAS accounts have a field for storing IRC nick. They do not have a
field for freenode credentials. We probably should have such a field?
- Upon activation (which is from a single hub IRC widget), we will
create an ircb user for them, log the user on to their given freenode
nick in FAS, and have them join the channel corresponding to the hub
they are on. If they would like to join additional channels, they'll
need to enable them from each respective hub page's IRC widget.
- If a user does not have a nick in FAS, we will prompt them to either
provide their registered freenode nick (maybe don't accept unregistered
nicks in the dialog?) and guide them through nick selection and
registration. We need mockups for this.
- Each IRC widget has a 1:1 mapping with an IRC channel. You cant switch
channels from inside the widget. The hubs admin determines, when adding
the IRC widget to their hub, what channel the widget is going to
display. If a hub wants more than one channel displayed (likely a very
rare case) they will need one widget channel.
- We have some architectural issues in terms of passing info between FAS
<=> hubs <=> wartaa <=> ircb. One basic example is having a
hover/rollover to display the Real Name of a user's IRC nick in the
channel log. Another is the IRC mention feature integration with the
hubs stream / messaging area. Sayan needs to do some more research on
this but believes we may not be able to use the iframe implementation of
waartaa as a result.
The state of what we have now:
- right now someone could start on updating the the user model and
adding a UI element to update the irc on/off setting. Nothing is
blocking that work and it needs to be done.
- we need a login mechanism - to log into freenode and triggered by
enabling IRC in the UI (logs in via waartaa to generate cookies.)
- the login page is made (provided by waartaa), sayan is currently
working on redux integration of the data sent back from the server.
waartaa is powered by aiohttp and react+redux
We had originally seta loose milestone of mid October 2016 with the 10
issues tagged 'milestone' from this list:
We've definitely made progress, but we're a couple of months past our
milestone and are stuck and/or blocked on the majority of our milestone
issues. So I think we are overdue to reassess where we are at and what
we're going to do toget Hubs up and making our fellow Fedorans more
We need to figure out how much time werealistically need to complete
these and figure out a new realistic date for making a release so we
don't lose momentum and stall out. If needed, we can pass issues over to
others if anybody doesn't realistically have time to work on their
issues; we can reassign issues and/or try to recruit morefolks to help
too. I think at this point we'll need to focus on recruiting experienced
developers to help us.
Let'shash through this at our next regular meeting.