Last modified: 2014-10-16 11:52:57 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T49540, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 47540 - Close components for archived/unmaintained Bugzilla components (and close remaining tickets?)
Close components for archived/unmaintained Bugzilla components (and close rem...
Status: NEW
Product: Wikimedia
Classification: Unclassified
Bugzilla (Other open bugs)
unspecified
All All
: Lowest minor (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-04-23 11:00 UTC by Liangent
Modified: 2014-10-16 11:52 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Liangent 2013-04-23 11:00:00 UTC
The first one, ABC, has been archived[1], for example.

Maybe also close existing open bugs as resolved wontfix?

[1] https://www.mediawiki.org/w/index.php?title=Extension:ABC&diff=622929&oldid=571606
Comment 1 Andre Klapper 2013-04-23 18:25:16 UTC
In general I agree, but who defines when an extension gets archived? :)
After how much time is an extension considered unmaintained?
(This is a general question, also in other FOSS projects, and I don't expect answers from you of course.)

Once Wikimedia SVN is shut down I was planning to go through Bugzilla extensions and close those ones that never got migrated to Git.

When closing as WONTFIX I prefer to add a whiteboard entry
    extension[unmaintained]
and an explaining comment, see e.g.
bug 17175 comment 2.
Comment 2 Andre Klapper 2013-08-31 21:48:42 UTC
I'm waiting for http://www.mediawiki.org/wiki/Community_metrics to provide enough statistics on development activity. 
Without good data it's hard to judge and back up decisions...

Next steps here could be to 
1) agree when an extension is considered unmaintained (which rather sounds 
   like a mailing list topic
2) whether this means that some actions should take place, and
3) what these actions would look like (as proposed here, for example actively
   trying to find new maintainers, judging whether continued maintenance is 
   wanted (e.g. does not make sense if code has been superseded anyway), 
   closing a Bugzilla component for new bug entry, tag and close remaining 
   open tickets, etc).

I'm not sure if this is stuff to discuss in this bug report, should really be a broader debate in the community, and information on maintenance status should also be properly reflected and announced on the affected extension homepages.
Comment 3 Quim Gil 2013-09-03 21:12:22 UTC
I'm also for cleaning Bugzilla. I don't think we need much mailing list discussion: just an email to wikitech-l warnoing about this report should be enough. Whoever cares about Bugzilla should be able to come here and discuss.  :)

Our work on community metrics won't be useful to answer these questions any time soon, since we are focusing on projects deployed in WMF servers or otherwise explicitly supported.

But a place to start could be 

http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/?sortby=date&sortdir=down

3 years or more without any code move might be a good sign of abandonment. A bug report could be opened warning about the Bugzilla component closure of Extension X, CCing the maintainers and last commit authors. If nobody is willing to step in to save it, the component would be closed in 60 days.

An alternative is to move the components to an Archived product.
Comment 4 Andre Klapper 2014-03-16 23:46:39 UTC
There was [[mw:Git/Conversion/Extensions still in svn]] (now archived).

Previously in case of lack of maintenance, I've resolved tickets in some components as RESOLVED WONTFIX, added "wikimedia[unmaintained]" to the status whiteboard (to be able to query to reopen in case of claiming maintainership again), added an explanatory comment (see e.g. bug 45290 comment 2), closed the component for bug creation, updated the component description. Plus one should make sure that the extension homepage on mediawiki.org reflects the lack of maintenance in a banner on top plus is in the "Obsolete extensions" category.

Refering to Quim's proposal of CC'ing maintainers and last committers, I like this.
When I closed unmaintained Bugzilla components in the past as described above, I sometimes had tried to contact past maintainers/developers, but mostly I relied on edits by 'trusted' users on the extension homepages updating its status to unmaintained, or public mailing list postings announcing the end of maintainership (and/or undeploying from Wikimedia servers) of a component.


So before working on resolving this bug report in an "organized" way, I'd like to wait for better [[mw:Community metrics]] so I could look up the date of the last development activity on a webpage instead of having to run "git log" on a local checkout of all extensions in Wikimedia Git. But maybe http://git.wikimedia.org/ already offers such a view and I have not found it yet? :-/
And furthermore, potentially creating a "Deprecated" classification in Bugzilla to reclassify/move these products and/or components under.

Reminder to myself: Once this is done, document the steps above on a dedicated wikipage under [[mw:Bug management]] linked from [[mw:Bug management/How to triage#Situation_specific_information]] and maybe maybe also from [[mw:Bug management/Triage tasks]].

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links