indieweb.org

From IndieWeb

This article is a stub. You can help the IndieWeb wiki by expanding it.


indieweb.org is the primary website of the IndieWeb community.

Primary Resource

indieweb.org is the starting point and primary resource of the IndieWeb community.

Everything we do starts on the main indieweb.org website.

In addition we have started using a small number of subdomains for very specific distinct uses.

2016 IndieWebCamps

So far we have used (and are actively using) 2016.indieweb.org for a couple of event pages to see how they can work (and be friendlier than our events overview or existing event pages)

Chat

We use https://chat.indieweb.org/ for our IRC discussion archives and Chat application with separate "sign in" than the main site. This is deliberate to provide a lower barrier to entry for informal chatting.

There is still some pending work to do to transfer all our previous IndieWebCamp chat functionality (e.g. Web UI to IRC) to the chat subdomain:

Etherpad

We use https://etherpad.indieweb.org/ for live collaborative document editing, also with a different "sign in", that is, none required at all.

Indie News

We use https://news.indieweb.org/ for aggregating indie news posts about the indieweb. It's like Hacker News, but you use your own site and peer-to-peer Webmentions rather than signing into yet another silo.


Why

identity

The IndieWebCamp community started based primarily around in-person IndieWebCamp meetups and thus that identity made sense for the founding and subsequent years.

Increasingly we are both self-identifying and being identified (in the media) more as the "IndieWeb" community.

Thus it makes sense to recognize that shift in identity with an explicit use and shift to "indieweb.org". See rename to IndieWeb for details on that transition.

On 2016-07-04 we switched to indieweb.org from indiewebcamp.com as our primary website (see rename to IndieWeb for project details).


Brainstorming

Additional brainstorming about indieweb.org

How

How do I document community problems

If you find a problem with community resources, it depends on the resource.

Many resources are on Github, or have Github issues for tracking:

Otherwise if the issues are specific to a page or a topic on the wiki, look for the "Issues" second level heading, and add items there.

How to improve community stuff

If I have an idea for improving a community resource, how can I do so?

Step 1: First document the problems you are seeing that you think need solving, per "How do I document community problems". Because we're a community, this step of first documenting what you think is a problem is much more important than sharing your idea(s) for a solution, no matter how well intentioned.

  • Avoid presumed solutions. Documenting solutions first is bad for several reasons:
    1. Anything that assumes specific solutions is putting the cart before the horse.
    2. No such "solutions" can/should be justified without first documenting the specific issues they are supposedly solving, and documenting such issues *first* and *separately* to encourage both multiple solution possibility thinking on the behalf of any one person, and the broader community.
    3. Putting solutions first also artificially constrains your solution thinking to one possible solution because then you debate do you like it or object to it instead of alternatives. It tends to blind you to other possibilities.
    4. Putting solutions first is offputting to and actually goes against the goals of actually helping the community and being more accessible to a broader set of the community and more generations, because people see it and think it's already been decided.


Step 2 Ask other people in IRC if they have encountered the problem(s) you found or what they think of them. You'll quickly find out one of the following:

  • Confirmation: that people have encountered the problem, or
  • Novelty: people have not, you may have found something new, or
  • Apathy: people don't respond, maybe what you think is a problem is not a problem for anyone else.

What you do next depends on how others in the community responded - this is a key part of doing work with a community, as opposed to presuming to do work for a community.


Step 3: Depending on the result of step 2:

  • Confirmation: ask the people that also encountered the problem to add to the issue you filed, and if they'd like to work with you on possible solutions.
  • Novelty: Ask the people that acknowledged the problem you pointed out if there are any details they'd like to add.
  • Apathy: Do nothing. You've found a supposed community problem that isn't impacting anyone else in the community, which means it's likely not a community problem at all. It might just be a matter of personal taste, where you have a difference with something in the community. Maybe consider working on your own website instead.


Step 4: Work with the community to brainstorm. Since you found confirmation or at least acknowledgment of the problems you found from specific people, work with at least those people in the community on brainstorming a solution. Document your brainstorms, preferably multiple ideas and proposals in a "Brainstorming" section on the relevant wiki page. Iterate. This step may take sometime


Step 5: Discuss, prototype, iterate. Discuss the various brainstorms, perhaps try prototyping a UX for them (use any of your own domains for this, no need to prototype on indieweb.org), gathering feedback on prototypes (practice active listening, especially to those raising doubts / questions about your proposals/prototypes), and then iterating.

Avoid: focusing on plumbing changes. If you focus on plumbing changes, instead of the UX of a prototype, of a solution, you'll likely get distracted with working on things that don't actually matter, that don't actually solve the documented problem. In particular be careful of switching to anything that's *less* accessible for editing/contributing by a broader community / next generations. Avoid anything much more dev-biased that would *hurt* not help broader community participation in therein.


Step 6: Get consensus. This may be the hardest step, but is essentially for actually improving the community. Keep iterating on your solutions until you have a consensus among interested/active folks in the community on what you are proposing. This is also a good reason to iterate on prototypes on your own domain. Even if you don't end up with something for the community as a whole, you may end up building a good separable web service that others can use / opt-in to on a separate domain.


General Problems With Subdomains

subdomains--. There are lots of problems with subdomain approaches both in general (e.g. coupling "As part of the move" is bad), and specific instances. Details at: https://indiewebcamp.com/irc/2016-06-20#t1466440239085 (to be expanded / itemized here inline) - or perhaps this is better for a subdomain page and Why / Why not sections. Tantek 10:56, 20 June 2016 (PDT) (updated 2016-07-5).

  • The only time you do actually want explicit subdomains is for different security contexts (e.g. CORS) for purposes of account ownership/login etc., e.g. what LiveJournal switched to. Tantek

docs subdomain

Use docs.indieweb.org for default wiki page URLs

  • Redirect all URLs on indiewebcamp.com to docs.indieweb.org
  • Set a temporary redirect from indieweb.org to docs.indieweb.org

Opinions:

  • -1 Tantek Çelik - There's no need for this, and a subdomain before "indieweb" dilutes the brand of "indieweb" (i.e. when copy/pasted/shared), is more to type (if/when people start thinking they must type it, like people errantly still type "www." when it isn't needed like 99% of the time.). "docs" is too narrow a name and mislabeled as well. there's much more than just "docs" on Indiewebcamp.com pages.
    • Feature of "no docs. subdomain": Having wiki-backed pages *by default* for any URL makes sense as it makes it easy to experimentally build out the site, and when it gains some amount of structure in an area that could use a different UX, then we can override that subsection with custom HTML etc. without having to change URLs, domains etc. This is in direct contrast to any concerns about "namespace collision", which are hypothetical, where as the ability to use wiki by-default for pages is a real advantage that we are both using currently (real world experience), and the *absence* of doing so in other communities (e.g. microformats.org) demonstrated that was a weaker model, with the CMS/static pages going out of date as compared to the wiki-based pages over time.
    • Beware of politician's syllogism fallacy with regards to jumping to subdomain/plumbing/backend/CMS changes, i.e.: "This is a problem (content + design e.g. of homepage)" and then "Something (subdomains/plumbing changes) must be done." It does not follow, and worse, wastes time *not* solving the actual problem. Solving the actual problem would be putting forth copy-edits, new content/UX designs etc. Not proposals for subdomain/backend changes which do not actually touch the content/design (or only incidentally do because of different default templates).
  • -1 Aaron Parecki - However, I would like to reserve the option of replacing the MediaWiki home page with a simple HTML/PHP file so that we can customize and style it more, details TBD. Currently there's a custom index.php hack there to get MediaWiki to not redirect / to /Main_Page anyway.
    • +1 Tantek Çelik The option, method, and implied reasoning (as needed) both make sense, and are minimal/easy-to-use "simple HTML/PHP" so I both agree, and am willing to help with that (as I'm sure lots of others with HTML/PHP skills are).
  • -1 gRegor Morrill - agreed with above. https://www.mediawiki.org/wiki/Extension:SkinPerPage may be an option to skin the homepage differently while still being a wiki page (I know. more extensions, yay!)
  • -1 Kyle Mahan - important to me that some of the URLs that get cited often like indiewebcamp.com/principles or indiewebcamp.com/site-deaths stay short and memorable.
  • +1 bear
  • +1 Shane Becker - Avoids URL/wiki URL namespace collision. The wiki is too intimidating to drop new people into (even with a simpler/cleaner homepage), especially for later generations, but even for early generations too.
    • Tantek Çelik Agreed with the problem statement of "wiki is too intimidating to drop (some) new people into", however I disagree on your conclusion. Content/design problems require focusing on content/design changes rather than subdomain/backend changes. Added more reasoning to my opinion above.
  • -1 Kevin Marks - wiki fallback for unknown pages is a feature
  • +1 Brennan Novak - definitely agree with Shane Becker that the wiki is intimidating to newcomers. Wikis lack information architecture but they are great with engaging content that is densely interlinked (e.g. Wikipedia), but not so good for figuring out where in an experimental new tech community to engage & participate or get an overview. By making the root site *indieweb.org* into something more curated and "thought out" will force the content to be more easier to browse and engage with for newcomers
    • Tantek Çelik Agreed on goal of more curated and "thought out" content that is easier to browse and engage with for newcomers. You have a good problem statement. Content/design problems require focusing on content/design changes rather than subdomain/backend changes. Added more reasoning to my opinion above.
  • -1 Ben Roberts seems silly since this is 99% of our content. Also the missing pages being easily creatable is a nice feature.


Other variants regarding docs.

Static home page, wiki on subdomain

  • Main home page at indieweb.org lives outside of the wiki
  • Jekyll site [1]
  • Pages can "graduate" from the wiki to this site when we feel they better address a later generation
  • The MediaWiki install moves from indiewebcamp.com to docs.indieweb.org
    • Will continue to be used as we use our current wiki, for documenting research and patterns, etc

Wiki as home page

  • Move the wiki to indieweb.org
  • Use MediaWiki syntax plus custom HTML/CSS on the page to create the new home page design

Custom HTML/CSS/PHP for home page

  • Move the wiki to indieweb.org
  • Have a separate index.php page for the home page
  • Content for the index.php page can come from the wiki or be edited on GitHub
  • Also gives us an opportunity to dynamically script some content such as upcoming events
  • Note that for technical reasons, there is currently an index.php page on indiewebcamp.com which actually fetches the wiki Main_Page and passes it through


People and Profiles

Why People and Profiles

We currently have at least 4 places on the wiki that someone's profile information is saved:

This is awkward when we ask newcomers to add themselves to the wiki, since there are initially two places they should add themselves. Creating a user page is a great way to let people add some basic links about themselves as well as document their interest in the indieweb, but we also ask people to add themselves to chat-names as that is how the IRC logs and Slack bridge map their IRC nickname to their URL and profile photo.

People Directory Goals

The goal of a People Directory is to be the canonical directory of people involved with indieweb.org, consolidating our use of profile information on the wiki. When other parts of the system (such as the IRC logs, or Loqi in IRC) need to look up profile data, they can find it at this site. This also enables us to provide a better experience to newcomers since we can tailor the process of logging in and creating a profile to be friendly, rather than dumping people into a mediawiki form that has no prompts.

Additionally, this site can act as an h-card validator and generator. When someone is first creating their profile, it can initially look at their home page for h-card information to pre-populate fields. This means it can also poll their sites occasionally to keep the information up to date. If the person has no h-card on their site yet, they can enter their profile data directly, and the site can generate a basic h-card that they can then copy+paste to their website.

Naturally, this directory must also have the ability for people to enter unstructured content on their profiles, so that we can continue to let people use it to document their "itches" or other indieweb projects as we do today.

David Shanske - "The idea of itch user pages is something I always felt should move to people's own sites...I should say on my own site what I want to do there. That said, I agree with the idea of a people directory, but I disagree with the idea that it allows people to enter unstructured data on their profiles for the reason I think that should be somewhere else. I think the advantage of this comes with letting people, as suggested, generate h-cards to copy-paste, but otherwise, it should not let people store their h-card data. This is a great opportunity to build another community building block, but I think it should be structured as a service used by various Indieweb sites."

  • I fully support people having their itches on their own sites, or even elsewhere like GitHub. However, some people like using the wiki to document their itches, and some people use it to document their itches before they have anywhere on their site they are comfortable documenting them. The goal behind this "people" project was to move what essentially became a people directory off of the wiki onto something easier to use, while not losing functionality people currently have with the wiki. Aaron Parecki 19:17, 21 June 2016 (PDT)


Login Service

Why a Login Service

Currently, wiki logins are handled through a MediaWiki plugin.

  • Upgrading the wiki means making changes to the plugin since there have been changes to the MediaWiki hooks between versions.
  • There has been some talk of having the wiki login bypass indieauth.com if the user has delegated to their own authorization endpoint, the wiki should use it directly instead of directing the user to indieauth.com (this will improve the UX for people signing in with their own auth endpoints)
  • Building MediaWiki plugins is a chore, and as we have seen, require maintenance to keep up with MediaWiki core upgrades.
  • If another site like the events site requires login, it will be better UX (and easier to build) if all the logins are handled through a single point.

Login Brainstorming

Create a new website specifically for logging in to all web apps on indieweb.org. Logins for the wiki and all subdomain websites are all handled through this site. This site implements the IndieAuth protocol, including using your own authorization-endpoint if you have specifically delegated to one, otherwise using indieauth.com to implement rel-me-auth.

After signing in, the website sets a root domain cookie that is sent to the website and any subdomains, so they can extract the login information from the cookie and not have to implement sign-in themselves.

For static web pages, this site can also provide a Javascript shim that will load a header bar showing the logged-in state of the user and provide a login form.

Backups

Currently, the wiki is available in backup forms via Bittorrent Sync, rsync, and HTTP (see wiki/backup) We will need to ensure each component of the new organization has the ability to be backed up as well. The easiest way to enable simple backups of all the content is for each application to publish plaintext or JSON content (in format that can be easily restored) of each page at a URL, and then provide another URL that links to all pages. An example of how the current wiki does this is here: https://indiewebcamp.com/wiki/backup/data/

We can then create a separate project (backups.indieweb.org?) that consolidates all the text content from each site into a folder, and makes it available via git, rsync, http, etc, encouraging multiple people to maintain copies of the data.

Inspiration

Take a look at other similar community wiki sites for alternative perspectives, content organization, design inspirations etc.:

Retrieved from "https://indieweb.org/wiki/index.php?title=indieweb.org&oldid=93315"