A question on the catalog
Locked
 
|
Hi,
I was doing a pass on the catalog… I think is very negative that non-documented projects appear there… because most people does not know what does projects are about and newcomers will find weird a project install tool with lots of projects without any description. So I was thinking on put an option “show all” and hide those projects by default… but now I think those projects SHOULD NOT BE VISIBLE AT ALL, as a way of: - offer better experience to non-power users, and - encourage people to actually document their projects… is very annoying to have so much of them without any documentation. What do you think? cheers, Esteban |
|
|
Hi Esteban,
On Fri, Jun 10, 2016 at 02:52:46PM +0200, Esteban Lorenzano wrote: > Hi, > > I was doing a pass on the catalog??? I think is very negative that non-documented projects appear there??? because most people does not know what does projects are about and newcomers will find weird a project install tool with lots of projects without any description. > So I was thinking on put an option ???show all??? and hide those projects by default??? but now I think those projects SHOULD NOT BE VISIBLE AT ALL, as a way of: > > - offer better experience to non-power users, and > - encourage people to actually document their projects??? is very annoying to have so much of them without any documentation. > > What do you think? Rather than hiding projects that people were legitimately allowed to add (at the time), why not modify the catalog to not accept projects that don't have sufficient metadata, including the description? IIRC there was some discussion about hiding or lowering the priority of projects that haven't been modified or confirmed as working in the latest versions of Pharo. That would still be useful. Between the two, that would get rid of undocumented projects. Just my 2c, Alistair |
|
|
In reply to this post by EstebanLM
Esteban
The current catalog is an inbox. We should define the rules for the real ones and validate the entries. Entries that are not described should not be put in the real catalog. Stef Le 10/6/16 à 14:52, Esteban Lorenzano a écrit : > Hi, > > I was doing a pass on the catalog… I think is very negative that non-documented projects appear there… because most people does not know what does projects are about and newcomers will find weird a project install tool with lots of projects without any description. > So I was thinking on put an option “show all” and hide those projects by default… but now I think those projects SHOULD NOT BE VISIBLE AT ALL, as a way of: > > - offer better experience to non-power users, and > - encourage people to actually document their projects… is very annoying to have so much of them without any documentation. > > What do you think? > > cheers, > Esteban > |
|
|
In reply to this post by alistairgrant
Hi,
> On 11 Jun 2016, at 08:53, Alistair Grant <[hidden email]> wrote: > > Hi Esteban, > > On Fri, Jun 10, 2016 at 02:52:46PM +0200, Esteban Lorenzano wrote: >> Hi, >> >> I was doing a pass on the catalog??? I think is very negative that non-documented projects appear there??? because most people does not know what does projects are about and newcomers will find weird a project install tool with lots of projects without any description. >> So I was thinking on put an option ???show all??? and hide those projects by default??? but now I think those projects SHOULD NOT BE VISIBLE AT ALL, as a way of: >> >> - offer better experience to non-power users, and >> - encourage people to actually document their projects??? is very annoying to have so much of them without any documentation. >> >> What do you think? > > Rather than hiding projects that people were legitimately allowed to add > (at the time), why not modify the catalog to not accept projects > that don't have sufficient metadata, including the description? it is not possible right now, and the hiding would work as the same. people were legitimately allowed is also relative… truth is that most undocumented projects comes from MetacelloRepository (the original one) and there was no catalog nor metacello toolbox :P but most important: most of those projects are unmaintained projects are will not load anyway, so they are not just source of noise, they also can make the community looks bad, I think. > > IIRC there was some discussion about hiding or lowering the priority of > projects that haven't been modified or confirmed as working in the > latest versions of Pharo. That would still be useful. well, hiding them would certainly “lower the category”. My first approach (toggle hide/show) would work... > > Between the two, that would get rid of undocumented projects. > > Just my 2c, > Alistair cheers, Esteban |
|
|
In reply to this post by stepharo
> On 11 Jun 2016, at 09:17, stepharo <[hidden email]> wrote: > > Esteban > > The current catalog is an inbox. We should define the rules for the real ones and validate the entries. > > Entries that are not described should not be put in the real catalog. yes, but validation rules is something for the future. What do we do with the ones that now are in the inbox but do not fulfils the minimum requirements? This requires a fix now, and the possible fix is hide them… and report the non documented projects to this list, so people who maintain them can document it. so, ideal: have a monkey process to run validations for newly added packages (btw, Pavel, I think the same “catalog-updater” script can be extended for this. possible right now: not showing the ones who are bad documented and then report periodically which ones should be documented. Esteban > > > Stef > > > Le 10/6/16 à 14:52, Esteban Lorenzano a écrit : >> Hi, >> >> I was doing a pass on the catalog… I think is very negative that non-documented projects appear there… because most people does not know what does projects are about and newcomers will find weird a project install tool with lots of projects without any description. >> So I was thinking on put an option “show all” and hide those projects by default… but now I think those projects SHOULD NOT BE VISIBLE AT ALL, as a way of: >> >> - offer better experience to non-power users, and >> - encourage people to actually document their projects… is very annoying to have so much of them without any documentation. >> >> What do you think? >> >> cheers, >> Esteban >> > > |
|
|
right now
We should remove the ones with no documentation. Or let us in Pharo 60 we only accept the ones with documentation. Le 11/6/16 à 10:17, Esteban Lorenzano a écrit : >> On 11 Jun 2016, at 09:17, stepharo <[hidden email]> wrote: >> >> Esteban >> >> The current catalog is an inbox. We should define the rules for the real ones and validate the entries. >> >> Entries that are not described should not be put in the real catalog. > yes, but validation rules is something for the future. > What do we do with the ones that now are in the inbox but do not fulfils the minimum requirements? This requires a fix now, and the possible fix is hide them… and report the non documented projects to this list, so people who maintain them can document it. > > so, ideal: have a monkey process to run validations for newly added packages (btw, Pavel, I think the same “catalog-updater” script can be extended for this. > > possible right now: not showing the ones who are bad documented and then report periodically which ones should be documented. > > Esteban > >> >> Stef >> >> >> Le 10/6/16 à 14:52, Esteban Lorenzano a écrit : >>> Hi, >>> >>> I was doing a pass on the catalog… I think is very negative that non-documented projects appear there… because most people does not know what does projects are about and newcomers will find weird a project install tool with lots of projects without any description. >>> So I was thinking on put an option “show all” and hide those projects by default… but now I think those projects SHOULD NOT BE VISIBLE AT ALL, as a way of: >>> >>> - offer better experience to non-power users, and >>> - encourage people to actually document their projects… is very annoying to have so much of them without any documentation. >>> >>> What do you think? >>> >>> cheers, >>> Esteban >>> >> > > |
Re: A question on the catalog
|
|
In reply to this post by EstebanLM
2016-06-11 10:17 GMT+02:00 Esteban Lorenzano <[hidden email]>:
OK!
|
|
First of all how many are undocumented ? Do we have any statistics ? Personally I don't thinks it's a huge issue because most people use catalog as an easy install and not to discover new packages. I have not even bothered to read the ones that are documented. Frankly I don't mind because I always document and if I need a package I will just document it.
On Sat, 11 Jun 2016 at 12:44, Pavel Krivanek <[hidden email]> wrote:
|
|
|
On Sat, Jun 11, 2016 at 12:14 PM, Dimitris Chloupis <[hidden email]> wrote: First of all how many are undocumented ? Do we have any statistics ? 252/407 (~62%) For me +1 for removing/hiding undocumented ones. I would also propose to add a method having just the link to the original repo, whether that's smalltalkhub or github, and show that in the catalog browser. Peter |
|
|
I don't thinks it's a huge issue because most people use catalog as an easy install and not to discover new packages. Do you have any evidence to back up "most people" claim? We don't have any good mechanisms to discover Pharo projects and catalog is frankly the most complete one (although a fulltext search in description would be nice). On Sat, Jun 11, 2016 at 12:55 PM, Peter Uhnák <[hidden email]> wrote:
|
|
|
The emphasis here is "I dont think" so this is a personal assumption not a fact based theory. So I would not talk about evidence but indications , I have been an active participant of the pharo community for 4 years now. There are not many messages that I have missed in Pharo-dev or Pharo-users or even the IRC and Slack channels. Though lately it has become harder to keep, which yes its a an awesome thing ;)To quote another developer "documentation is not an obligation its just a necessity for success" On Sat, 11 Jun 2016 at 14:06, Peter Uhnák <[hidden email]> wrote:
|
|
|
In reply to this post by EstebanLM
On Sat, Jun 11, 2016 at 4:12 PM, Esteban Lorenzano <[hidden email]> wrote:
> Hi, > >> On 11 Jun 2016, at 08:53, Alistair Grant <[hidden email]> wrote: >> >> Hi Esteban, >> >> On Fri, Jun 10, 2016 at 02:52:46PM +0200, Esteban Lorenzano wrote: >>> Hi, >>> >>> I was doing a pass on the catalog??? I think is very negative that non-documented projects appear there??? because most people does not know what does projects are about and newcomers will find weird a project install tool with lots of projects without any description. >>> So I was thinking on put an option ???show all??? and hide those projects by default??? but now I think those projects SHOULD NOT BE VISIBLE AT ALL, as a way of: >>> >>> - offer better experience to non-power users, and >>> - encourage people to actually document their projects??? is very annoying to have so much of them without any documentation. >>> >>> What do you think? >> >> Rather than hiding projects that people were legitimately allowed to add >> (at the time), why not modify the catalog to not accept projects >> that don't have sufficient metadata, including the description? > > it is not possible right now, and the hiding would work as the same. > > people were legitimately allowed is also relative… truth is that most undocumented projects comes from MetacelloRepository (the original one) and there was no catalog nor metacello toolbox :P > but most important: most of those projects are unmaintained projects are will not load anyway, so they are not just source of noise, they also can make the community looks bad, I think. I agree its discouraging to see lots of blank descriptions when browsing the catalogue. Indeed it makes me wonder "is it working", which is bad. However I see something like Aconcagua which probably is very useful to have a catalog entry for, but maybe their it has no definite "owner" in our community. A solution besides completely hiding them would be to have an [Undocumented] tab. Then if the Catalog Browser had a help topic with a recipe on how to update the description of undocumented entries (download/modify/upload) perhaps(?) it would be easier for the community to contribute to updating them, than if they never appeared. I think our community image is maintained if the undocumented projects are segregated in this way. I think mainly brand/image suffers when deficiencies turn up in "official" looking locations. Not so much if its a designated badlands. It about user expectations and surprises. The default description might advise these were imported from a time before the catalog description field was defined, and refer to the help topic to request help updating the descriptions. cheers -ben > >> >> IIRC there was some discussion about hiding or lowering the priority of >> projects that haven't been modified or confirmed as working in the >> latest versions of Pharo. That would still be useful. > > well, hiding them would certainly “lower the category”. My first approach (toggle hide/show) would work... > >> >> Between the two, that would get rid of undocumented projects. >> >> Just my 2c, >> Alistair > > cheers, > Esteban > > |
|
|
In reply to this post by EstebanLM
On 11/06/2016 10:13 AM, "Esteban Lorenzano" <[hidden email]> wrote:
> > Hi, > > > On 11 Jun 2016, at 08:53, Alistair Grant <[hidden email]> wrote: > > > > Hi Esteban, > > > > On Fri, Jun 10, 2016 at 02:52:46PM +0200, Esteban Lorenzano wrote: > >> Hi, > >> > >> I was doing a pass on the catalog??? I think is very negative that non-documented projects appear there??? because most people does not know what does projects are about and newcomers will find weird a project install tool with lots of projects without any description. > >> So I was thinking on put an option ???show all??? and hide those projects by default??? but now I think those projects SHOULD NOT BE VISIBLE AT ALL, as a way of: > >> > >> - offer better experience to non-power users, and > >> - encourage people to actually document their projects??? is very annoying to have so much of them without any documentation. > >> > >> What do you think? > > > > Rather than hiding projects that people were legitimately allowed to add > > (at the time), why not modify the catalog to not accept projects > > that don't have sufficient metadata, including the description? > > it is not possible right now, and the hiding would work as the same. Pity, it would also be nice to ensure that all submissions are marked with the version they have been tested against. > people were legitimately allowed is also relative… truth is that most undocumented projects comes from MetacelloRepository (the original one) and there was no catalog nor metacello toolbox :P > but most important: most of those projects are unmaintained projects are will not load anyway, so they are not just source of noise, they also can make the community looks bad, I think. By "legitimately" I just meant that the system didn't reject them when they were submitted. I also expect at least some people were unaware that a description could be added. I only found our when I switched to using Versionner. > > > > > IIRC there was some discussion about hiding or lowering the priority of > > projects that haven't been modified or confirmed as working in the > > latest versions of Pharo. That would still be useful. > > well, hiding them would certainly “lower the category”. My first approach (toggle hide/show) would work... > > > > > Between the two, that would get rid of undocumented projects. Thanks! Alistair |
|
|
Pity, it would also be nice to ensure that all submissions are marked This is done by commiting to the appropriate MetaRepoXY (where XY is Pharo version). Although I mentioned to Esteban that having MetaRepo60 right now is a bit broken idea, because if you commit there now and Pharo changes later, there is no guarantee that it would even load. Peter |
|
|
We will sit down with Pavel. I was thinking that we should have a process like this one: Inbox50 -> validated for current version -> pushed into
distribution 50 -> not validated -> moved into currently not working for distribution 50
inboxCurrentAlphaVersion (ie 60) -> validated for current version -> pushed
into distribution 60 => revalidated for each
new version -> not validated -> moved into currently not working for distribution 60
Le 12/6/16 à 23:11, Peter Uhnák a
écrit :
|
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |