search

trilinos / trilinos.github.io

Trilinos Project Homepage
https://trilinos.github.io
30 stars 23 forks source link

Organize Packages Drop-down menu best understandability and usability #33

Open maherou opened 4 years ago

maherou commented 4 years ago

The Packages drop-down menu was recently re-organized to provide the reader with some guidance as to:

While the current names and groupings are an improvement of the previous single list of package names, there may be a better way to organize and classify the packages.

This issue is intended for capturing ideas and defining a how to improve the organization.

bartlettroscoe commented 4 years ago

@maherou, some feedback

I just noticed that the "Packages" drop-down at the top of:

Now shows them partitioned into several different categories:

I am not sure who came up with the selection of packages in those lists but they are not consistent. Here are some examples of consistencies:

jhux2 commented 4 years ago

A few comments:

1) In the drop down, I see this: "The MPI+X collection of packages is sometime referred to as the Tpetra stack." In fact, I always refer to the Epetra stack or the Tpetra stack, never MPI+X. How would a user approach this?

2) What are the definition of research packages? Stokhos and Teko are integral components of ATDM apps, so I would argue they could be production ....

I appreciate that you're trying to instill some order for someone new to Trilinos. I just suspect Trilinos might not be amenable to such simple categorizations.

maherou commented 4 years ago

@bartlettroscoe , @jhux2: Thanks for your comments.

While there are obvious mistakes with the initial placement of packages, what I am trying to accomplish is:

Once we determine a way to describe useful categories, we can work out the details of where a package belongs. I thought about our categories of production-growth, production-maintenance, etc., but these are also not as descriptive. If you have suggestions for categories and names, I would like to see them. Perhaps we could also consider non-exclusive categories (so some packages could appear in more than one category).

bartlettroscoe commented 4 years ago

@maherou, I am with @jhux2; Trilinos packages are going to be hard to classify in strict separate lists like this.

I think I see what you are trying to do with "Archive Packages". With the exception of RTOp, those are all packages that you can disable (or replace with some other Trilinos package like replacing Rythmos with Tempus) and you would not impact any current important customers of Trilinos.

The problem with this is that RTOp is a required dependency of Thyra. Until a refactoring is done to replace this with a more modern C++11/14 version based on Kokkos, it will still be getting used in production applications through Thyra. That is not true of any of the other packages listed under "Archive Packages".

Again, ForTrilinos is not strictly a Trilinos package because it is not in the Trilinos repo, but it is an add-on package (using the TriBITS add-on repo/package mechanism). But I see it is hosted under the github.com/trilinos/ organization. Therefore, would you not need to list every add-on package listed there including Sundance, CTrilinos, and xSDKTrilinos (the former two as "Archive Packages" and the last as "Research Packages")? What about other add-on packages like DataTransferKit? That is not maintained under the Trilinos organization. What is the criteria for what is considered a "Trilinos package" and what is not?

jhux2 commented 4 years ago

Clearly distinguish between the software packages that are used in production, those that can be used in a non-production environment and still have someone on the development team who cares about the package, and packages that never met the threshold of broad usability and never will.

By "can be used in a non-production environment", does this mean packages that are not production ready but are still supported/developed?

If you have suggestions for categories and names, I would like to see them. Perhaps we could also consider non-exclusive categories (so some packages could appear in more than one category).

I like the idea of non-exclusive categories. Depending on what the categories are, a Venn diagram might be helpful.

mperego commented 4 years ago

@maherou, What if we only have two categories. The packages currently-developed/essential, and the "obsolete" packages (i.e. Epetra stack etc.). We could also color code the packages to indicate their level of maturity (I think @kddevin proposed this).

maherou commented 4 years ago

I think there is value to identifying packages like the core Epetra stack that are production quality vs those that never made it to broad use. We still hear of Trilinos users who want the parallel environment that the Epetra stack provides.

jhux2 commented 4 years ago

I think there is value to identifying packages like the core Epetra stack that are production quality vs those that never made it to broad use. We still hear of Trilinos users who want the parallel environment that the Epetra stack provides.

I agree. But I think @mperego might be pointing out that the Epetra stack is no longer developed.

maherou commented 4 years ago

Agreed. However, I think we want at least three categories. I don't think we want to combine Epetra with packages like Optika, which never made it out of the gate.

mperego commented 4 years ago

That's fine. We could also decide to list in that drop-down menu only the "most relevant" packages, and have the others (e.g. optika, but possibly also shards,RTOp, that are mainly support packages) listed in the respective products pages. Just an idea.