The wikis are now using the new authentication system.
If you did not migrate your account yet, visit https://idp-portal-info.suse.com/

Opensuse-docs/prep-meeting-10-23

Jump to: navigation, search

<<< back to Documentation:Meetings

[@ad_himself https://t.me/ad_himself]

October 15, 2020

Hello friends, sorry for keeping you waiting. We are glad to have you in and are looking forward to get things done. Just so that you know who "we" is, that is @adathor Loquacity @IvoErMejo @DevDorrejo @andres_bs and myself -- please forgive me all the others I couldn't name.

Next meeting

We'd like to have a video meeting next week, with the goal of organizing ourselves into subgroups. We are not quite sure when this meeting should take place because so please take the survey below this message. So far we've been using time *between* meetings to explain, debate and discuss things, so that the meeting *in itself* is used to register a vote or something like a group consensus. There is no guarantee that we will always agree on everything, but at least this makes for a nice workflow, since we can make concrete steps forward instead of using everyone's time to do bookkeeping tasks.

Things to do

1. Structure ourselves (see next section)

2. Check that nothing is missing from this list (https://docs.google.com/document/d/1zERjqqQrWBAoM3B25BIQ4hvTFU_Y7S8L57bh-wb6ld4/edit?usp=sharing) of issues that the refreshed learning experience (no matter the format) should cover.

3. Starting to test out different solutions for hosting our contents (see the "Platform Testers subgroup in the next section").

Things to think through before the next meeting

We are quite numerous and so are the things on the todo list. So I think it's important we agree on certain keys roles that should be filled between us to make sure we're all pulling on the same rope. I've discussed this with @adathor and we agree on these roles -- you'll forgive my extravagant descriptions, just meant to fix ideas (see next paragraph).

So beside taking the survey I've just posted in the Telegram group, it would be nice if you could tell us:

if you agree or disagree with this way of structuring ourselves if you agree but have in mind less or more roles (please share the details of your constructive counter-proposal) if you agree to everything, which role(s) you'd like to fill in. You can do this now in the Telegram chat or send me a message if you'd prefer. Please let me know if anything is not clear.

Roles

  • The Keeper of Continuity (1 person): makes sure no one is left behind, takes minutes in meetings and tries to keep the mailing list people in the loop, keep tabs on who does what, etc.
  • The Seekers of Truths (many people): collectively ensure that every item on the Long List is true and can be safely recommende. In some corner cases (i.e. the '?' items on the List) that might mean ringing some devs or experts, listing pros and cons, and explain why the pros prevail eventually.
  • The Collectors of Most Pressing Issues (many people): they scan all openSUSE-relevant communication channels and make basic stats of the most pressing issues (frequence x painfulness), make them bubble up to us so that we are not building an ivory tower of abstract idea nobody needs
  • The Video People (many but not too many because this is quite niche and can become a mess if too many people cook in the same kitchen): select high-profile topics and issues, provide customization tips, desktop environment tip, workflow tips, etc. Something you mentioned in your version of the list makes me think the Video people could really help present and visually explain tasks that span over different platforms (i.e. basically everything I sorted under "Give back to the community"). I don't think it was their primary goal but in terms of what would best benefit the end-users I smell great value here.
  • The Platform and Interface Testers (several people): let's be honest we will never find the perfect infrastructure for hosting our contents unless we run tests. The issue is that when you making a list of boxes your want your infrastructure to tick, then you find out that perhaps you didn't pick the right boxes, because form and contents are related in complex ways. Perhaps a simple approach here is to try to do everything from a wiki, and then deviate as minimally as possible whenever we are trying to do something the wiki can't, and finally see if all the deviations really pay off. But yeah probably the best of all worlds is something between the wiki and what the unofficial guides available at https://opensuse-guide.org/. It should at least provide:
full-text search easy update method
a "view things as a sequence" (as the unofficial guides) view and a "view things as thematically related because you need answers about something in particular" view (as for example here: https://getsol.us/help-center/home/)
a "show more / show less" flip switch to adapt to the knowledge of the user

Also there is one idea that we should take into account for selecting a platform: if we want to we can just ditch the "view things as a sequence" presentation and get the people that made the installer to turn it into a web app -- in fact a "install my openSUSE simulator". I don't think this is very difficult to do technically as the installer is written in some high-level language (Ruby?) which is very web-oriented in the first place. This means we would also have to get them to add extra infoboxes to cover all our needs, and to have the "show more / show less" flip switch. If we go down this road the docs get a little bit more tractable: just

the "installation simulator"; and the full-text searchable knowledge base as the solus thing I linked above (https://getsol.us/help-center/home/).

Good examples of clean "interactive" docs presentation