There are two issues with the project hub:

- People don't realize that git repo != project on sr.ht, and never make
  sr.ht projects for their git repositories. Bad habit learned from
  GitHub.
- sr.ht projects aren't publically listed until you complete or dismiss
  the checklist. The intention is to give you time to set up your
  project before it shows up in the public index. Bad UX from sr.ht that
  this process is not made clear.

Ideas on how to solve these two issues?

On 2020-09-22 13:13:02, Drew DeVault wrote:
> - People don't realize that git repo != project on sr.ht, and never make
>   sr.ht projects for their git repositories. Bad habit learned from
>   GitHub.

Part of the problem might be that there is no indication whether a Git
repository is part of a project when visiting the repository.  If there
were links to the project and maybe the associated trackers and mailing
lists, it would be easier to notice the difference and it would be an
incentive to create projects (to make it easier to navigate).

/Robin

On September 22, 2020 11:26:11 AM MDT, Robin Krahl <robin.krahl@ireas.org> wrote:
>Part of the problem might be that there is no indication whether a Git
>repository is part of a project when visiting the repository.

This matches what I've been thinking for a bit: you can go down from a project to the repos/issues/lists it contains, but you can't go up from those back to the project unless the README etc has a link to the project root specifically added. I think it would be nice for that link to be traversable in both directions.

On Tuesday, September 22, 2020 1:26:11 PM EDT Robin Krahl wrote:
> Part of the problem might be that there is no indication whether a Git
> repository is part of a project when visiting the repository.  If there
> were links to the project and maybe the associated trackers and mailing
> lists, it would be easier to notice the difference and it would be an
> incentive to create projects (to make it easier to navigate).
I think that just having project components link back to the project home 
would be a step in the right direction.

-- 
Best,
Owen Salter

> - People don't realize that git repo != project on sr.ht, and never make
>   sr.ht projects for their git repositories. Bad habit learned from
>   GitHub.

On your view, you would prefer to swap that logic? Having a project,
then creating/associating repositories?

I see that there's plenty of repos that aren't a project per se. For
instance, bare, most of your wayland works, static sites, etc.

> - sr.ht projects aren't publically listed until you complete or dismiss
>   the checklist. The intention is to give you time to set up your
>   project before it shows up in the public index. Bad UX from sr.ht that
>   this process is not made clear.

Maybe simply enforce that on the project creation process?

Instead of a tiny dismiss button, replacing that with a Publish Project
button; Instead of a "new project checklist" expand that into a more
"onboard-like experience", guiding people on how to do the process, etc.

On Tue Sep 22, 2020 at 2:57 PM EDT, Pedro Lucas Porcellis wrote:
> On your view, you would prefer to swap that logic? Having a project,
> then creating/associating repositories?

It depends on the individual user's goals for that work.

> I see that there's plenty of repos that aren't a project per se. For
> instance, bare, most of your wayland works, static sites, etc.

Aye, but as someone who knows the difference, I've deliberately chosen
not to list these as projects.

> > - sr.ht projects aren't publically listed until you complete or dismiss
> >   the checklist. The intention is to give you time to set up your
> >   project before it shows up in the public index. Bad UX from sr.ht that
> >   this process is not made clear.
>
> Maybe simply enforce that on the project creation process?
>
> Instead of a tiny dismiss button, replacing that with a Publish Project
> button; Instead of a "new project checklist" expand that into a more
> "onboard-like experience", guiding people on how to do the process, etc.

Hm, yeah, changing the language could go a long ways here.

On Tuesday, September 22, 2020 2:57:51 PM EDT Pedro Lucas Porcellis wrote:
> Maybe simply enforce that on the project creation process?
> 
> Instead of a tiny dismiss button, replacing that with a Publish Project
> button; Instead of a "new project checklist" expand that into a more
> "onboard-like experience", guiding people on how to do the process, etc.
I like this idea. I think making it clearer that completing/dismissing the 
checklist will make the project discoverable would be an improvement.

-- 
Best,
Owen Salter

On 22/09/2020 19:13, Drew DeVault wrote:
> - People don't realize that git repo != project on sr.ht, and never make
>    sr.ht projects for their git repositories. Bad habit learned from
>    GitHub.

I have two suggestions, mostly concerning the words "people don't 
realize" - so it means teach the users, through UX:
- as mentioned by others: links from a project to existing trackers, 
proejcts, mailing lists
- if it doesn't exist, add a "Create a project for this repository so 
you can add issue tracker and a mailing list".


> - sr.ht projects aren't publically listed until you complete or dismiss
>    the checklist. The intention is to give you time to set up your
>    project before it shows up in the public index. Bad UX from sr.ht that
>    this process is not made clear.

I can think of two ideas:
- change the copy on the "dismiss" to "publish project". Pretty clear 
signal that the project is not public until that.
- add a step-progress bar above. Like "Step 1 of 2: project 
details"(name etc) and "Step 2 of 2: Optional checklist to go through".



-- 
Zlatko

On Sun, Sep 27, 2020 at 5:31 PM Zlatko Duric <zlatko@toptal.com> wrote:
>
> - if it doesn't exist, add a "Create a project for this repository so
> you can add issue tracker and a mailing list".

I found this thread while looking into how to add issue tracker to my
repo https://hg.sr.ht/~techtonik/discovery

Attaching issue tracker in Features submenu looks like a good solution
to me https://hg.sr.ht/~techtonik/discovery/settings/features

If it is not possible to attach a tracker without creating a project, then
the same submenu can be used to "Level up Repository to a Project".

-- 
anatoly t.

(sorry about the length; I'm having trouble collecting my thoughts
today)

From some chats on IRC, it looks like this might be the main thing
holding many users back from sourcehut. People who get linked straight
to a repo or mailing list don't know what the "hub" is or how to reach
it, and therefore are unable to reach the other parts of a project.

Problem: A new user who stumbles upon a "git.sr.ht" or "hg.sr.ht" link
won't know to remove the "git." or "hg." subdomain from the URL to find
the lists, tickets, etc.  Said user also won't know how to navigate to
the different sub-sections of the active section (i.e., navigate from
one mailing list to a different mailing list, or from one repo to
another repo). In fact, it isn't obvious that other
sections/sub-sections of the project even exist.

For example, let's say I have never heard of sourcehut before and
someone linked me straight to this thread's web interface. I should
quickly be able to figure out the following three things:

1. I am on the "sr.ht-discuss" mailing list.
2. This is one of multiple mailing lists under the "mailing lists" tab
   of the "sourcehut" project
3. I can switch to the sources, website, or tickets tabs of the
   "sourcehut" project

Now, let's say that there's a clear and obvious way to go to the hub.
The user would see this, but wouldn't know the purpose of the hub: a
place to discover the sources, website, tickets, and lists of a project.
The three things I listed wouldn't obvious until AFTER I blindly
navigate to the project hub. In other words, making the hub discoverable
provides the means to discover it, but not a reason to do so.

Perhaps we could keep the hub's tab bar on all the project's pages with
the active section highlighted, and provide a separate location to
display which sub-section is active. I don't know the ideal way to
present both pieces of information, but one option would be to keep the
project hub's tab bar on all project pages and introduce a sidebar to
display the active and available sub-sections. Another option that's
less cluttered but also less obvious and informative would be to have
breadcrumbs at the top.

On more "mainstream" forges, someone browsing issues, the repo, PRs,
etc. is aware of and can navigate between each of these sections because
they are available in a tab bar (GitHub, Gitea) or sidebar (GitLab).

-- Seirdy

“I apologize for such a long letter - I didn't have time to write a
short one.” --Mark Twain

Sorry again, this time for the double-email. I've both compiled my
thoughts and refined my opinion a bit. You can disregard my previous
email if you'd like.

The page for a repository, issue tracker, or mailing list archive should
make a new user aware of the existence of other mailing lists, issue
trackers, repositories. It does not need to tell the user the names of
or links to each list, tracker, or repo; instead, It should make the
user aware that a project hub has more detailed information, and provide
a clear way to navigate to it.

In other words, we need to both make the user aware of the larger
project's elements and a way to discover them. A very ugly, wordy,
messy, yet otherwise effective way to do this would be to put a notice
on the top of every page. For example:

"lists.sr.ht/~sircmpwn/sr.ht-discuss part of the project
sr.ht/~sircmpwn/sr.ht. Visit <the project hub> for lists, repos, and
tickets."

The opposite would also be helpful: repos and lists that aren't part of
a bigger project could display something more clear than "unlisted". I
don't have any good ideas on what that could be.

We should probably have a videoconf sometime to brainstorm solutions,
since visual aids (e.g. whiteboards) are helpful when designing visual
interfaces ;). I'll make a new thread for that.