Diff for "Registry/UpstreamLinkUbuntu"

Not logged in - Log In / Register

Differences between revisions 1 and 7 (spanning 6 versions)
Revision 1 as of 2010-01-28 19:43:06
Size: 2517
Editor: sinzui
Comment:
Revision 7 as of 2010-01-28 22:43:24
Size: 6866
Editor: sinzui
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from Registry/LinkUpstreamLinkUbuntu
Line 9: Line 10:
  * Launchpad could provide information about what each package needs to send upstream to make the need specific and clear.
  * Since crowd sourcing is the preferred solution to collect this information, karma can be awarded and top contributors can be displayed.
  * Launchpad could provide specific information that other communities need to know about what each upstream project, and make it clear when the information is missing.
  * Since crowd sourcing is the preferred solution to collect this information
     * karma can be awarded to users who privide community/service information.
     * Launchpad could allow contributors to add information that project owners have not provided.
Line 12: Line 15:
     * It could search for matching projects for the contributor and ask him or her to select from a list.
     * It could show exactly what information is missing
    * It could make project registration easier by pre-populating the form with the source package information.
     * It could search for matching Ubuntu packages for the upstream contributor and ask him or her to select from a list.
     * It could show exactly what information is missing.
Line 17: Line 19:
== Distro series +index page (updated) == == Product +index page without packages (updated) ==
Line 19: Line 21:
{{attachment:distroseries.png | alt distroseries index page | align="right"}} {{attachment:no-packages-in-ubuntu.png | alt packages in Ubuntu portlet (no packages) | align="right"}}
Line 21: Line 23:
The distroseries index page needs a portlet that encourages users to link source packages to registered upstream projects. The product index page has a portlet that shows distribution packaging, but nothing is shown on this page when there is no packaging.
Line 23: Line 25:
This proposed design is very similar to the portlet Curtis and Martin discussed in August 2009 when redesigning the project and distro series pages. The project series index page lists where to get the code as the second most important portlet so that user can start working on bugs and features. The same activity is hard to do in a distro series because most of the work must be forwarded upstream, or upstream needs their latest code sent upstream to Ubuntu. A different kind of portlet is needed by the distro series.

  * The portlet summarises the work that must be done.
  * The portlet must list a subset of the packages that need linking. The list is prioritised so that the users see the most urgent packages first.
  * The portlet could show recently linked packages
     * Showing recent activity encourages contributors to be a part of the group.
     * Showing who and when it was done give contributors exposure
  * The portlet has links to both the linked packages and unlinked packages views.

The recently linked listing breaks portlet conventions by showing the who and when on the same line as the what. This information is collected but has never been shown in the Launchpad UI.
The project page could show a portlet that asks contributors to select the Ubuntu package from a list of probably candidates.
  * The portlet must states why the links are valuable.
  * The portlet must make is clear that the candidated are for the currect Ubuntu development series.
     * Upstream projects are more interested in what their users use (the current or LTS release).
     * Upstream projects have often created false packages (that were never published in an Ubuntu series) to indicate that a package was made. The package was probably made in a PPA.
  * The portlet could make it clear that the packaging link is the the Upstream project's development series
  * The portlet must offer a link to select other packages and prodect series if the candidates are wrong.
Line 36: Line 35:
  * Curtis: The query to create the prioritised list of packages that need linking is hard.  * Curtis: There are some concerns about using this portlet:
   * This portlet could be very annoying to project that are not packaged in Ubuntu. I do not think this should be something that can be disabled by the project owner. Is there something intrinsic about some project that indicate this portlet should never be shown.
   * The portlet is shown at the bottom of the page? Can it be moved higher? It can be argued that it should be shown closers to the bugs and blueprints portlets because some project do make packages, but they are not linking them to Ubuntu.'
   * Can the portlet be moved closer to the series and milestone portlet because that shows releases?

||||||<tablestyle="clear: both;"> ||


== Product +index page with packages (updated) ==

{{attachment:packages-in-ubuntu.png | alt packages in Ubuntu portlet (packages) | align="right"}}

The product index page has a portlet that shows distribution packaging. It can be improved.

  * The portlet can be renamed "Packages in Ubuntu" to clarify the intent.
  * The portlet can show the most recent packages first.
     * The current portlet shows the oldest first
     * Older entries look wrong because the binary package release was removed, so there is less information to display.
     * Older entries are not as important to newer ones, users and developers will agree on this point.
  * The portlet can provide a link to register more packages that the upstream project provides.
     * This packging links are normally

=== Comments ===

 * Curtis: There are some concerns about using this portlet:
    * Who uses the portlet? It's primary existence appears to be a window to the +packages page.
       * Users do not use this because it does not provide them with an archive to add to their sources.
       * Power users could use it to navigate to a the deb, but that is 4 clicks away for knowedgeable Launchpad users.
       * Contributors can use this to get to the packages in recent Ubuntu series, but upstream care most about the current Ubuntu series, not the Ubuntu development series.
       * Contributors can use this to learn what the most recent version is in each Ubuntu series.
    * Why so many packages? 5 will ensure that the last LTS is always listed

||||||<tablestyle="clear: both;"> ||


== Product +ubuntupkg page (new) ==

Launchapd currently shows the links to add an ubuntu package on the product series pages (and with the series listings on Product +packages) because the series is used to create the packaging link.

Launchpad can provide an alternate +ubuntupkg form for Products that lets the contributors select the product series. The current development series can be the default value.
Line 40: Line 78:


== Project community services (New) ==

The Official Launchpad usage information is too simple. It acts as a flag, ignoring the fact that communities need to know who, what, and where to contact essential services.

The "Uses Launchpad for" section of Project Information must be replaced by something that presents the essential services: bug tracker, code hosting, translations, blueprints, and answers.
  * The presentation can be simple when launchpad hosts the service.
  * Some basic info is needed when the hosting is remote.
  * When information is missing, the page must encourage users to provide it.

Launchpad can allow owners to change the the information from an inline edit link. Any

=== Comments ===

 * Curtis:
   * blueprints, and answers can be argued to be unimportant, but I suspect we already have this information, or can add it in time. Project wikis are used for blueprints. forums and mailing list are used for answers.

||||||<tablestyle="clear: both;"> ||


== Product and product series permissions (update) ==

Is knowledge power if you cannot act upon it?

Many projects are missing upstream information. The project owner is not interest in providing it, or is absent, or the project is owned by the Registry Administrators. Contributors cannot fix the information, so they struggle to contact someone with the power to make the fix.
  * Launchpad can change the permision rules to permit contributors to set missing information on the product an series. The common fields that contributors need access to are: bug tracker, bug contact, series branch, series filereleaseglob, import/export translations.

=== Comments ===

 * Curtis:
    * Maybe communities need permission to create alternate product series. The power is restricted to project drivers aimed are creating a release. Communities may need permission to create series for experimental features or packaging.

Upstream linking to Ubuntu

Launchpad must make it easier for upstream contributors to link their projects to Ubuntu source-packages.

Launchpad has had packaging links for years, but the message regarding its value is not compelling.

  • Launchpad could provide specific information that other communities need to know about what each upstream project, and make it clear when the information is missing.
  • Since crowd sourcing is the preferred solution to collect this information
    • karma can be awarded to users who privide community/service information.
    • Launchpad could allow contributors to add information that project owners have not provided.
  • Launchpad could do some of the monotonous work for the contributors:
    • It could search for matching Ubuntu packages for the upstream contributor and ask him or her to select from a list.
    • It could show exactly what information is missing.

Product +index page without packages (updated)

alt packages in Ubuntu portlet (no packages)

The product index page has a portlet that shows distribution packaging, but nothing is shown on this page when there is no packaging.

The project page could show a portlet that asks contributors to select the Ubuntu package from a list of probably candidates.

  • The portlet must states why the links are valuable.
  • The portlet must make is clear that the candidated are for the currect Ubuntu development series.
    • Upstream projects are more interested in what their users use (the current or LTS release).
    • Upstream projects have often created false packages (that were never published in an Ubuntu series) to indicate that a package was made. The package was probably made in a PPA.
  • The portlet could make it clear that the packaging link is the the Upstream project's development series
  • The portlet must offer a link to select other packages and prodect series if the candidates are wrong.

Comments

  • Curtis: There are some concerns about using this portlet:
    • This portlet could be very annoying to project that are not packaged in Ubuntu. I do not think this should be something that can be disabled by the project owner. Is there something intrinsic about some project that indicate this portlet should never be shown.
    • The portlet is shown at the bottom of the page? Can it be moved higher? It can be argued that it should be shown closers to the bugs and blueprints portlets because some project do make packages, but they are not linking them to Ubuntu.'
    • Can the portlet be moved closer to the series and milestone portlet because that shows releases?

Product +index page with packages (updated)

alt packages in Ubuntu portlet (packages)

The product index page has a portlet that shows distribution packaging. It can be improved.

  • The portlet can be renamed "Packages in Ubuntu" to clarify the intent.
  • The portlet can show the most recent packages first.
    • The current portlet shows the oldest first
    • Older entries look wrong because the binary package release was removed, so there is less information to display.
    • Older entries are not as important to newer ones, users and developers will agree on this point.
  • The portlet can provide a link to register more packages that the upstream project provides.
    • This packging links are normally

Comments

  • Curtis: There are some concerns about using this portlet:
    • Who uses the portlet? It's primary existence appears to be a window to the +packages page.
      • Users do not use this because it does not provide them with an archive to add to their sources.
      • Power users could use it to navigate to a the deb, but that is 4 clicks away for knowedgeable Launchpad users.
      • Contributors can use this to get to the packages in recent Ubuntu series, but upstream care most about the current Ubuntu series, not the Ubuntu development series.
      • Contributors can use this to learn what the most recent version is in each Ubuntu series.
    • Why so many packages? 5 will ensure that the last LTS is always listed

Product +ubuntupkg page (new)

Launchapd currently shows the links to add an ubuntu package on the product series pages (and with the series listings on Product +packages) because the series is used to create the packaging link.

Launchpad can provide an alternate +ubuntupkg form for Products that lets the contributors select the product series. The current development series can be the default value.

Project community services (New)

The Official Launchpad usage information is too simple. It acts as a flag, ignoring the fact that communities need to know who, what, and where to contact essential services.

The "Uses Launchpad for" section of Project Information must be replaced by something that presents the essential services: bug tracker, code hosting, translations, blueprints, and answers.

  • The presentation can be simple when launchpad hosts the service.
  • Some basic info is needed when the hosting is remote.
  • When information is missing, the page must encourage users to provide it.

Launchpad can allow owners to change the the information from an inline edit link. Any

Comments

  • Curtis:
    • blueprints, and answers can be argued to be unimportant, but I suspect we already have this information, or can add it in time. Project wikis are used for blueprints. forums and mailing list are used for answers.

Product and product series permissions (update)

Is knowledge power if you cannot act upon it?

Many projects are missing upstream information. The project owner is not interest in providing it, or is absent, or the project is owned by the Registry Administrators. Contributors cannot fix the information, so they struggle to contact someone with the power to make the fix.

  • Launchpad can change the permision rules to permit contributors to set missing information on the product an series. The common fields that contributors need access to are: bug tracker, bug contact, series branch, series filereleaseglob, import/export translations.

Comments

  • Curtis:
    • Maybe communities need permission to create alternate product series. The power is restricted to project drivers aimed are creating a release. Communities may need permission to create series for experimental features or packaging.

Registry/UpstreamLinkUbuntu (last edited 2010-02-23 01:32:48 by edwin-grubbs)