1:07 p.m.
Hi everybody,
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)
- #fedora-hubs
Here's a summary of what we discussed today with a link at the bottom to
full logs:
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:
https://pagure.io/fedora-hubs/issues?status=Open&tags=milestone1
- ACTION NEEDED: taggingIRC tickets and other essential tickets with
'milestone1' tag.
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:
https://pagure.io/fedora-hubs/issue/2
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:
http://freenode.net/kb/answer/registration)
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
Full logs:
https://meetbot.fedoraproject.org/fedora-hubs/2017-01-11/hubs-devel.2017-...
Cheers,
~m